Icxolu

I think it makes sense to allow `[pyo3(from_py_with= ...)]` there, given that extracting types directly is already allowed. I implemented a fix in #4117, which should now handle them correctly.

How about allowing `#[pyo3(signature = ...)]` on complex enum variants to specify the constructor signature? Like so: ```rust #[pyclass] enum Thing #[pyo3(signature = (x = None, y = 0, z...

Thanks! Glad you like it. Yes, if people think the syntax and functionality proposed above is workable I'll open a PR from that. Given that ` #[pyo3(signature = ...]` is...

I don't really have much experience here, but would it help if we remove the fast path from these operations, and make reference count updates of `Py` always go through...

Could we provide the `Clone` impl for `Py` only under that feature flag? That would eliminate the panic and make it a compile error. Cloning would still be possible by...

> The problem I see is that you might want to still clone `Py` values to e.g. fulfil trait requirements of Rust types but ensure by context that you have...

I've played around with this some more, and added more conversions for experimentation. (I will remove most of the impls again from here, once we reached some consensus, since many...

One point to consider is whether `IntoPyObject ` should take `Self` by value or by reference. I believe typically in such a conversion one would take it by value to...

> As with e.g. `IntoIterator`, I think the trait should take `self` (by value) and we would implement it for for references `&'a T` where applicable. That makes sense, I...

> A reason against the generic overloads is type inference. True, and type hints for generic traits are always a bit awkward, because one can't use a turbo fish on...