[WIP] FromPyObject for #[pyclass] with T: Clone

[davidhewitt]

I had an idea how to support extracting for pyclasses automatically for T: Clone.

It also has really nice error messages if the user attempts to extract a non-clone #[pyclass] (see the ui test).

Closes #706

[kngwyu]

Nice 👍 , thank you.
But please wait for the review for a while, since I want to check we can simplify the implementation or not.

[davidhewitt]

Sure thing, take as long as you like!

I tried myself to do some simplifications but couldn't get much further than what's above.

It is possible to add some blanket impl FromPyObjectImpl for &T and &mut T, for example. But it's not possible to also have a blanket impl for T because it conflicts with the other two.

[davidhewitt]

I did spot a slight simplification!

Also, I realised that if I work the FromPyObject implementation for Vec<T> using this new FromPyObjectImpl trait, we can get the buffer::Element optimization without specialization. See davidhewitt#1

It isn't perfect and it's really un-ergonomic to have to implement FromPyObjectImpl for everything to get Vec<T> to work.

So we might want to think a bit longer about this idea. I think if we can find a nice API for it then we can use it to remove specialization from impl FromPyObject for Vec<T>.

[kngwyu]

Sorry for the lazy review, but after playing around the code, I'm really convinced that this is almost the minimal change 👍
All my review suggestions are optional and I don't have strong opinions about them.

[kngwyu]

Just a note:
I added this PR to 0.9.0 milestone since somehow rust-numpy needs this fix.

[davidhewitt]

Ok. I'm closing in on a design I like for the Vec<T> specialization solution (see the PR I linked in comment above).

Once that's ready I'll open it as a PR against pyO3 and then we can choose whether to take this simpler change, or the bigger design change from that PR.

[davidhewitt]

I've addressed all your comments and squashed to a single commit. One thing I've pointed out for you but otherwise this is ready to merge.

Having thought about the Vec<T> specialization more, the design I've settled on does not impact this design any more. So please merge this PR without waiting for whatever I come up with there.

[davidhewitt]

This is the only change which you might want to check. I think this is acceptable?

[kngwyu]

👍

[kngwyu]

Thank you!