-
Hi all. I've been working with Here is a simplified reproduction of what I'm seeing fn custom_fn(obj: &pyo3::Bound<pyo3::PyAny>) -> pyo3::PyResult<OtherType> {
Ok(OtherType {
other_field: 0
})
}
pub struct OtherType {
pub other_field: u32,
}
// No compilation error if I remove `pyo3::IntoPyObject` here
#[derive(pyo3::FromPyObject, pyo3::IntoPyObject)]
pub struct MinimalRepro {
#[pyo3(from_py_with = "custom_fn")]
pub field: OtherType,
} and the compiler error we receive error: expected `attribute` or `item`
--> src/repro.rs:163:12
|
163 | #[pyo3(from_py_with = "custom_fn")]
| ^^^^^^^^^^^^ Is it possible to use I'm using Thanks for the assistance. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
I agree this should be supported and would consider this a bug on PyO3s side. The problem here is that derive macros declare the same Currently I can see two ways to solve this:
This is scratching the same issue David pointed out in #4850 (comment) (even though that one resolved itself in a different way) from a different angle. I tend to think that the first options is probably acceptable. We could still reject unknown/misspelled/incompatible options and give appropriate errors, but would have to allow some no-op options on each derive. As a workaround you could create a wrapper type around that field and implement |
Beta Was this translation helpful? Give feedback.
I agree this should be supported and would consider this a bug on PyO3s side. The problem here is that derive macros declare the same
#[pyo3]
attribute and thus get passed the same set of options. However they both only accept a subset of all options and reject everything else, i.e.IntoPyObject
does not know what to do withfrom_py_with
. So this problem is present for all attributes that are not common between these two.Currently I can see two ways to solve this:
serde
does. This would solve the error, but the experience around single derive and meaningless options is a bit worse.