David Hewitt

> Replace the implementation with `PyObject_GetIter` and `PyIter_Next` (slow?) I think we should seriously consider going this way and benchmark if it's actually a performance concern. We already made the...

> Yea this is really bad, but kind of expected as `dict.items()` creates a copy of the iterable and saves it into a PyList. > > https://github.com/python/cpython/blob/main/Objects/dictobject.c#L3381-L3432 `dict.items()` is equivalent...

👍 thanks! I will try to read tonight or tomorrow evening!

See also #1647, I think `int` is a `PyVarObject` like `tuple`. If we were fixing this, I think it would also likely help with #1344.

A thought to consider here, should we invert this and have `final` instead of `subclass`? Imo most python users expect to be able to subclass things...

Thanks for the question & offer to help. You are exactly right, and there's even a (years-old) FIXME in our code to make this happen: https://github.com/PyO3/pyo3/blob/52dc139142df0c48fab6f77f9edd96204bfa02c1/src/pyclass_init.rs#L65 I think personally I'd...

(Sorry fat finger error in closing!)

```rust super::() .new_args(args, kwargs) .build(Self) ``` This is probably not quite the right API, but the main point to make is that what I think we'll have to do is...

I think this is a case where PyO3 needs improving; our current `#[new]` does nothing to handle `__init__` . I think probably the simplest thing to do is for us...

Interesting idea. Those names remind me a bit of #4413, however in this case I really like the suggestion of using `new0`, `new1` etc. This will directly map to eventually...