docs: major rewrite for Bound API#3906
Conversation
CodSpeed Performance ReportMerging #3906 will not alter performanceComparing 🎉 Hooray!
|
guide/src/python_from_rust.md
Outdated
|
|
||
| * [`call`]({{#PYO3_DOCS_URL}}/pyo3/prelude/trait.PyAnyMethods#tymethod.call) - call any callable Python object. | ||
| * [`call_method`]({{#PYO3_DOCS_URL}}/pyo3/prelude/trait.PyAnyMethods#tymethod.call_method) - call a method on the Python object. | ||
| * It provides global APIs for the Python interpreter, such as [`py.eval()`][eval] and [`py.import()`][import]. |
There was a problem hiding this comment.
| * It provides global APIs for the Python interpreter, such as [`py.eval()`][eval] and [`py.import()`][import]. | |
| * It provides global APIs for the Python interpreter, such as [`py.eval_bound()`][eval] and [`py.import_bound()`][import]. |
guide/src/types.md
Outdated
| PyO3's API offers three generic smart pointers: `Py<T>`, `Bound<'py, T>` and `Borrowed<'a, 'py, T>`. For each of these the type parameter `T` will be filled by a [concrete Python type](#concrete-python-types). For example, a Python list object can be represented by `Py<PyList>`, `Bound<'py, PyList>`, and `Borrowed<'a, 'py, PyList>`. | ||
|
|
||
| ## The Python GIL, mutability, and Rust types | ||
| These smart pointers have different numbers of lifetime parameters, which defines how they behave. `Py<T>` has no lifetime parameters, `Bound<'py, T>` has a lifetime parameter `'py`, and `Borrowed<'a, 'py, T>` has two lifetime parameters `'a` and `'py`. |
There was a problem hiding this comment.
If we make a point here about these, we should also explain what these lifetimes describe, not just that they are there.
What does 'py describe? Is it the same for Bound and Borrowed? What about 'a?
Or we remove this here and defer to the detail sections below.
There was a problem hiding this comment.
Tried to expand on this a bit.
guide/src/types.md
Outdated
|
|
||
| By having the binding to the `'py` lifetime, `Bound<'py, T>` can offer the complete PyO3 API at maximum efficiency. This means that in almost all cases where `Py<T>` is not necessary for lifetime reasons, `Bound<'py, T>` should be used. | ||
|
|
||
| `Bound<'py, T>` engages in Python reference counting. This means that `Bound<'py, T>` owns a Python object. Rust code which just wants to borrow a Python object should use a shared reference `&Bound<'py, T>`. Just like `std::sync::Arg`, using `.clone()` and `drop()` will cheaply implement and decrement the reference count of the object (just in this case, the reference counting is implemented by the Python interpreter itself). |
There was a problem hiding this comment.
| `Bound<'py, T>` engages in Python reference counting. This means that `Bound<'py, T>` owns a Python object. Rust code which just wants to borrow a Python object should use a shared reference `&Bound<'py, T>`. Just like `std::sync::Arg`, using `.clone()` and `drop()` will cheaply implement and decrement the reference count of the object (just in this case, the reference counting is implemented by the Python interpreter itself). | |
| `Bound<'py, T>` engages in Python reference counting. This means that `Bound<'py, T>` owns a Python object. Rust code which just wants to borrow a Python object should use a shared reference `&Bound<'py, T>`. Just like `std::sync::Arg`, using `.clone()` and `drop()` will cheaply increment and decrement the reference count of the object (just in this case, the reference counting is implemented by the Python interpreter itself). |
There was a problem hiding this comment.
Also, drive by comment: Arg should be Arc
|
I feel the lack of understanding how #[pyfunction] works. What should I specify as return type. Same with args. I believe that there is a hidden type conversation behind the scene. So I'm confused should I return Bound<> or PyObject... which will not cause type conversation. Should I use PyResult<&str> or return PyResult of Bound PyString. Should I accept args as refs of not. Unfortunately, most code snippets utilize PyResult<()> as the return type :( I will be happy to find answers to these questions in the docs Speaking of v0.20 I was surprised to gain a huge performance bust by -fn _decode_dag_cbor(data: Vec<u8>) -> Result<Ipld> {
+fn _decode_dag_cbor(data: &[u8]) -> Result<Ipld> {I wish to not make this mistake again |
Co-authored-by: Lily Foote <code@lilyf.org>
Co-authored-by: Lily Foote <code@lilyf.org>
|
Thanks, I've added a new section specifically talking about the function argument lifetimes to help indicate to use I'd like |
guide/src/conversions/traits.md
Outdated
| - apply a custom function to convert the field from Python the desired Rust type. | ||
| - the argument must be the name of the function as a string. | ||
| - the function signature must be `fn(&PyAny) -> PyResult<T>` where `T` is the Rust type of the argument. | ||
| - the function signature must be `fn(Bound<PyAny>) -> PyResult<T>` where `T` is the Rust type of the argument. |
There was a problem hiding this comment.
This can also take a &Bound<PyAny> I believe
There was a problem hiding this comment.
I think it is actually just &Bound<PyAny> for now.
There was a problem hiding this comment.
If we want to keep this section referencing the gil-refs for now, we probably should backport the the examples again, otherwise this does not make a lot of sense
Co-authored-by: Icxolu <10486322+Icxolu@users.noreply.github.com>
Co-authored-by: Icxolu <10486322+Icxolu@users.noreply.github.com>
Co-authored-by: Adam Reichold <adamreichold@users.noreply.github.com>
Icxolu
left a comment
There was a problem hiding this comment.
Looks good 🚀 ! There is still calling-existing-code.md to rework, but I think it's fine to merge this as is for the beta and then finish the docs towards final release.
Co-authored-by: Adam Reichold <adamreichold@users.noreply.github.com>
|
Thanks everyone for the reviews! Definitely there's more the docs can have improved, though I think this PR really did shift the bulk of them onwards and upwards 💹 |
I started these on the weekend but ran out of time to go any further, I'll try to continue with these in the next couple of days...