Add IntoPyObject & FromPyObject for Arc<T>

[bschoenmaeckers]

Closes #4887.

This PR adds IntoPyObject and FromPyObject for Arc by forwarding the conversion to &T. Since we can’t access T, we work around the naming of associated types by adding extra type parameters. This fixes the conversion error when using #[pyclass(get)] with Arc fields.

[Icxolu]

Interesting workaround. I wonder whether the additional type parameters have any impact on type inference. Did you perhaps tested/noticed anything in that regard? Maybe with the derive macro?

Also: Is it sufficiently clear that a roundtrip with Arc will not give the same Arc? Or should we document that somewhere?

[bschoenmaeckers]

I wonder whether the additional type parameters have any impact on type inference. Did you perhaps tested/noticed anything in that regard? Maybe with the derive macro?

I didn't experience any weird inference behaviour when writing the existing test. The new macro tests behaves fine so I think we are good there as well.

Is it sufficiently clear that a roundtrip with Arc will not give the same Arc? Or should we document that somewhere?

I am not sure if it needs explicit documentation, as all roundtrip conversions create new objects, why would this one differ? That said documentation doesn't hurt nobody.

[davidhewitt]

One alternative possibility here is that we change the pyclass internals so that instead of only being able to store T they can also store a range of different containers which deref to T.

I imagine mostly that would be Arc and Box but maybe also more complicated designs where the T is actually stored as data on a separate python object and the data is just borrowed from there.

[bschoenmaeckers]

I imagine mostly that would be Arc and Box but maybe also more complicated designs where the T is actually stored as data on a separate python object and the data is just borrowed from there.

I do not fully understand your second case. Can you give me a example of a class definition?