docs: Improves IntoPyObject documentation in the guides#5835
docs: Improves IntoPyObject documentation in the guides#5835
IntoPyObject documentation in the guides#5835Conversation
…tructs and tuples.
… and `#[derive(IntoPyObjectRef)]`.
…readability and consistency.
Cheukting
changed the title
IntoPyObject documentation in the guides [WIP]IntoPyObject documentation in the guides
Icxolu
left a comment
Icxolu
left a comment
There was a problem hiding this comment.
Thank you for working on this! I spotted a few things and left comments below.
guide/src/conversions/traits.md
Outdated
| # } | ||
| ``` | ||
|
|
||
| Similar to `FromPyObject`, the argument passed to `get_item` can also be configured: |
There was a problem hiding this comment.
For IntoPyObject the item attribute refers to the key used in the set_item/__setitem__ call.
guide/src/conversions/traits.md
Outdated
| ``` | ||
|
|
||
| This tries to convert a mapping with the key `"key"`. | ||
| The `item` can take any valid literal that implements `ToBorrowedObject`. |
There was a problem hiding this comment.
ToBorrowedObject looks like something old that does not exist anymore. Today I think it just takes any valid literal.
guide/src/conversions/traits.md
Outdated
| You can also use `#[pyo3(from_item_all)]` on a struct to convert every field to be used with `get_item` method. | ||
| In this case, you don't need to use `#[pyo3(item)]` on each field. |
There was a problem hiding this comment.
from_item_all has no functionality for IntoPyObject since it exclusively uses set_item. It is just accepted for compatibility with FromPyObject. (Same is true for for other attributes as well, for example attribute or default)
guide/src/conversions/traits.md
Outdated
| For `enum`s each variant is converted according to the rules for `struct`s above. | ||
|
|
||
| ```rust,no_run | ||
| ```rust |
There was a problem hiding this comment.
It only makes sense to run these if there is main which does something, otherwise it is better to leave these as no_run for a faster test suite.
| - `pyo3(default)`, `pyo3(default = ...)` | ||
| - if the argument is set, uses the given default value. | ||
| - in this case, the argument must be a Rust expression returning a value of the desired Rust type. | ||
| - if the argument is not set, [`Default::default`](https://doc.rust-lang.org/std/default/trait.Default.html#tymethod.default) is used. | ||
| - note that the default value is only used if the field is not set. | ||
| If the field is set and the conversion function from Rust to Python fails, an exception is raised and the default value is not used. | ||
| - this attribute is only supported on named fields. | ||
|
|
There was a problem hiding this comment.
This one has no effect for IntoPyObject and we should not document it.
|
|
||
| #### `#[derive(IntoPyObject)]`/`#[derive(IntoPyObjectRef)]` Field Attributes | ||
|
|
||
| - `pyo3(item)`, `pyo3(item("key"))` |
There was a problem hiding this comment.
pyo3(item) is actually the default and only pyo3(item("key")) has the effect to use a different key
…er field attributes in `IntoPyObject` traits.
|
It is updated considering all your feedback and suggestions @Icxolu please feel free to check again |
2 participants
closes #5709