David Hewitt

I agree that adding `extract_sequence` to `FromPyObject` as proposed in the gist is very unsatisfying. That said, I've hit the `Vec` performance cliff myself in production (it can also cause...

I am happy to reopen this, as I agree the current situation around `Vec` is a performance footgun, both as an input and output argument to `#[pyfunction]`. Agreed that either...

Can I have a little bit more understanding why you can't use the existing proc macros? You say your classes are dynamically generated, can you just create a macro which...

👍 I am strongly in favour of making this an explicit opt-in; doing things automatically is not very idiomatic in Rust. I think it can be the same attribute as...

We may want to also consider the existence of such an attribute when thinking about design for `#[pyenum]` we have proposed for #1045, and `#[pyexception]` in #295 . Should they...

> In that case, I think #[pyclass(dataclass)] is preferable over #[pyclass(pod)] Note that `@dataclass` in Python also adds hash, repr and ordering - so we may want to provide an...

With #5624 merged this particular PR is no longer needed, but I would like to return to this and merge the change to move docs build inside the build script....

Thanks for the suggestion, it's an interesting idea. You present the trait, I guess users could call as ```rust // subject to type inference let (x, y, z) = Unpackable::unpack(obj)?;...

Hello, I agree with you that this is important; I've been aware of this shortcoming in PyO3's enum implementation and while I've wanted to fix it for a while I...

Yes - I think #3061 is part of the puzzle still missing. We should ideally have singleton values for each C-like variant and always be looking those up on the...