Author: Steve Dower
Created at: 2025-11-20 21:08
Number: 175
Clean content: Emma Smith: 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. Destabilising the existing C API isn’t an option, and providing a Rust abstraction over the unstable APIs doesn’t make them stable - they’re unstable because we want to be able to change them. If we didn’t want that, we’d make them stable or limited APIs. You can have PyO3 with access to unstable APIs already, presumably (perhaps without them being officially part of PyO3, but you aren’t being prevented by CPython from using them). If there are other APIs that are not currently public at any stability level that would be useful, we can discuss making them public. These problems are not good motivations for bringing Rust into core, since we already have the processes to manage them. They are good motivations for contributing to PyO3, which seems to be doing just fine without the restrictions and limitations that it would “enjoy” if it were part of core, and proposing new public APIs to the C API WG (who definitely enjoy dealing with those limitations). If a good first step to exposing subinterpreters (an existing core feature) was a module on PyPI, then I don’t see why a drop-in replacement for stdlib modules written in Rust can’t also start on PyPI. That way, distributors can immediately choose to include them instead of the core ones, and it’s much easier for core to later adopt an existing library than to approve what is currently a vague notion of “allowing” it.
