-
Notifications
You must be signed in to change notification settings - Fork 779
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* 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
|
||
## 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
`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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 <[email protected]>
Co-authored-by: Lily Foote <[email protected]>
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
@@ -484,7 +484,7 @@ If the input is neither a string nor an integer, the error message will be: | |||
- `pyo3(from_py_with = "...")` | |||
- 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This can also take a &Bound<PyAny>
I believe
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it is actually just &Bound<PyAny>
for now.
guide/src/memory.md
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good idea 👍
Co-authored-by: Icxolu <[email protected]>
Co-authored-by: Icxolu <[email protected]>
Co-authored-by: Adam Reichold <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 <[email protected]>
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...