David Hewitt

And (sorry to keep dangling ideas on here), inspired by the new `IntoPyObject`, I have two further perf related thoughts while we are making breaking changes here: - In the...

If we're breaking `FromPyObject`, I wonder if we can solve #2888 similar to how we handled bytes in `IntoPyObject` 🤔

Ah, nice research 👍. Agreed we can make a reminder for ourselves to improve bytes specializations once MSRV uses the next solve (gonna be a while 😂). Given the early...

One idea which struck me, what if we keep `FromPyObject` with just a single lifetime and `&Bound` as input, and we instead expose what's currently called `FromPyObjectBound` as `FromPyObjectBorrowed`? The...

Hmm, interesting. One nice thing about > one has to remember to implement `FromPyObject` if possible is that I'd guess most users would choose to implement it anyway as it's...

Sorry to have taken so long to circle back here. > I though about this some more recently while trying to add `FromPyObject::Error` (independently from this). It turns out that...

TLDR; I have thought hard about this over the last week and think this proposed design is the right one and we should move forward with it 👍 I think...

(And I'll hope that maybe in the long run the `'py` lifetime might be replaced by more advanced Rust language features so everything simplifies 😂)

Ah, and while we're updating this branch I think we should get the `Error` type in.

Related: I have been wondering for a while about a new call syntax and you have prompted me to actually write that up: #4414 Maybe we could have `py_call!{ PyValueError(a,...