Author: Emma Smith
Created at: 2025-11-20 21:53
Number: 181
Clean content: Steve Dower: emmatyping: 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. I think perhaps I may not have been clear in my earlier message, so apologies if not. I do not intend to destablize the C API, of course that is a non-starter. And I don’t intend to abstract over any unstable APIs either. What I imagine is a PyO3-like API abstracting the stable API. Then extension modules in the stdlib can also access the unsafe, unstable C APIs. The Rust FFI bindings will be kept up to date with the unstable C API so there is no issue with adding or removing functions. Steve Dower: 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. I see two reasons: The main reason subinterpreters started on PyPI, if memory serves, is to figure out the API design. PyO3 already has 8 years of experience for us to steal re-use refining their APIs. I expect the standard library abstractions over the stable API to be very, very similar to PyO3, except without support for PyPy and perhaps usage of internal APIs. A critical part of this proposal is understanding the impact of introducing Rust to CPython. We get no information from existing on PyPI. Steve Dower: jamestwebber: So what would be the next proposal after that? Write one, prove it’s better, propose stdlib inclusion. Great! So then once we have a prototype of the abstraction your concerns will be assuaged? James Webber: The point is not “we really need a faster base64 , and specifically it should be written in Rust”. It’s “we should think about introducing Rust. The minimally invasive way to do so is to start with an optional extension module ”. Absolutely, thank you for bringing this up. If you read over my earlier comment you will see that inclusion of base64 is not even a requirement for the overall goals of the pre-PEP.
