docs: update guide to mention GIL less#5381
Conversation
CodSpeed Performance ReportMerging #5381 will not alter performanceComparing Summary
Benchmarks breakdown
|
Icxolu
left a comment
Icxolu
left a comment
There was a problem hiding this comment.
Thanks for reworking this. I think our abstraction over GIL/free-threaded is coming together nicely. Just a couple of thoughts.
| Class objects can be used as arguments to `#[pyfunction]`s and `#[pymethods]` in the same way as the self parameters of instance methods, i.e. they can be passed as: | ||
| - `Py<T>` or `Bound<'py, T>` smart pointers to the class Python object, | ||
| - `&T` or `&mut T` references to the Rust data contained in the Python object, or | ||
| - `PyRef<T>` and `PyRefMut<T>` reference wrappers. |
There was a problem hiding this comment.
Should we also mention PyClassGuard here? Or do we wait with that until we deprecate PyRef eventually?
There was a problem hiding this comment.
I was wondering about it, I think it would be good to introduce PyClassGuard as part of 0.27 if we can figure out the way to sequence it in! I would prefer defer from this PR for the moment though.
Co-authored-by: Icxolu <10486322+Icxolu@users.noreply.github.com>
2 participants
Following on from all the work we did in PyO3 0.26 to move API names to be less dependent on the GIL, this takes a first pass at documentation (particularly in the guide) to do similar.
There's probably more to do, however this is all I had time for today, and I figure it's probably easier for reviewers to have not too much of this in one go.