Author: Emma Smith
Created at: 2025-11-20 20:05
Number: 171
Clean content: Mark Shannon: What is the proposed API for rust? The section on implementation talks about using bindgen, but what is the underlying C API that you are binding? The limited API or the warts-and-all “unlimited” API? To interact with the interpreter today, we need to interface with C APIs. Currently the proof of concept binds to the unstable Python APIs as well as internal ones. We definitely want to build safe abstractions over the raw C APIs for common use cases, and that could perhaps use an API like handles. But it has to wrap the existing APIs like HPy does for CPython, so these necessarily need to be exposed to Rust. Mark Shannon: You mention PY_OBJECT_HEAD_INIT but that just couples rust code to the deep internals of the VM. To define a module, we need to have some way of defining a PyModuleDef, unless we want to introduce a new module initialization protocol (which is a large proposal in of itself). Therefore we need a pointer to a PyModuleDef, which needs it’s first member to be PyModuleDef_HEAD_INIT which internally expands to a structure with it’s first member being PyObject_HEAD_INIT. So some of this coupling is necessary as part of the module initialization protocol. Changing this protocol could be something we look into, but seems like it’s own rabbit hole I realize this coupling is less than ideal, but any nicer HPy-like API would likely need to necessarily build on the existing C APIs, and I would like internal functions to be available to Rust modules just as they are to C modules in the standard library.
