limited pyo3 options when deriving both FromPyObject and IntoPyObject?

[Icxolu]

Currently combining the derive macros for FromPyObject and IntoPyObject limits the possible #[pyo3(...)] options to the union of options supported by both macros. It would be desirable to also allow individual options when combining them.

See also: #4883 (comment)

Discussed in #4883

^{Originally posted by baxtersa January 29, 2025}
Hi all. I've been working with FromPyObject for values passed as arguments from python code calling into Rust, but am having trouble implementing the IntoPyObject direction. We have a custom from_py_with function because one of our fields is a generic type with a const parameter, so we manually convert from a Vec to a fixed-size array. When adding the derivation for IntoPyObject, we get compiler errors on the pyo3(...) attribute saying error: expected 'attribute' or 'item'. Without derive(IntoPyObject), the rest of this code compiles just fine.

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 from_py_with when also deriving IntoPyObject? I have seen that something like into_py_with is in-progress too, so maybe this is just a current limitation?

I'm using pyo3=0.23.4.

Thanks for the assistance.