How to wrap a PyAny in a typeful API?

[kythyria]

I'm trying to write (a generator for) bindings for Blender's addon API, so I can call it from Rust (effectively using Python just as an ABI). The sticky point is, I can transmute from &PyAny to, say, &Mesh by defining the latter

#[repr(transparent)]
pub struct Mesh(PyAny);

but this leaves the questions of

1. how to convert a Bound<'py, PyAny> to a Bound<'py, Mesh> soundly?
2. how to do that with only very efficient checks for the correct type, (or mostly none at runtime, since the types involved are statically known)
3. if I really am stuck either with creating lots of traits or using alternative_self_types?

[davidhewitt]

Sorry for the long delay in response here. You may have come across the pyobject_native_type family of macros in PyO3's codebase which are used in PyO3 and rust-numpy to set up typeful APIs.

These macros haven't been added to the public API and documented yet, we've been working for a long time to figure out the Bound API which has solved several longstanding pain points with PyO3. I would be open to us figuring out how to make these macros part of the public API as we get the older "GIL Refs" API removed. But maybe these macros are mostly unnecessary once the GIL Refs API is gone.

In direct answer to your questions:

1. You should implement the PyTypeCheck trait for your Mesh type. This allows you to use .downcast::<Mesh>() using the check you defined.
2. You can use the unsafe .downcast_unchecked() function where you know the type must be correct.
3. Yes, I am afraid that this choice to have lots of traits was selected as the most agreeable option of the various design choices available to us. I think once you're used to it, the pattern of having Mesh and then PyMeshMethods which add methods to the Bound<'py, Mesh> smart pointer is quite predictable, even if there's a little bit of boilerplate. Maybe there is a way that PyO3 could make this pattern easier to use via a macro?

[kythyria]

I didn't realise PyTypeCheck was open to types that weren't part of Python itself: it transitively requires something implement PyNativeType, which claims to be only for such builtins. If it works for other types besides, that resolves a lot!

Not sure about macros, since I'm doing a pile of code generation of my own in this project, so long-winded definitions become part of that directly.

[davidhewitt]

Ah, that's understandable. PyNativeType and HasPyGilRef are part of the API which is being phased out, so hopefully the confusion (and complexity) will release in a future version.

[kythyria]

Re the boilerplate, I'm not sure if it's a good idea to reduce it by making MeshMethods: PyAnyMethods MeshMethods: Deref<Target=Bound<'py, PyAny>>, let alone representing inheritacne this way. It would let me make every single method provided though!

[davidhewitt]

Rather than super traits we've just been using the Deref implementation alone and relied on concrete typing to access PyAnyMethods. I'd be interested to hear how the supertrait bound goes for you.