Author: Emma Smith
Created at: 2025-11-18 04:11
Number: 59
Clean content: Jeong, YunWon: If there’s one aspect of RustPython worth highlighting in this PEP, it’s that it has achieved a surprising amount of CPython compatibility with a very small number of contributors. I rarely contribute directly to CPython’s C code, but I’m very familiar with reading it. After implementing equivalent features in RustPython, the resulting Rust code is usually much smaller, with no RC boilerplate, and error handling is much clearer. This is great to hear, and we’ll definitely note this in the PEP! Jeong, YunWon: In base64, the code currently uses a direct definition of PyModuleDef . To be safe, either: verify struct size via tests, or let C create the struct and only access it through FFI. As far as I can tell, cargo test for cpython_sys currently doesn’t run the generated tests (I might have missed something). I agree adding tests for the struct size is a good idea. And I’ll add a comment to get the bindgen tests working on the PR. Thanks for the feedback! Jeong, YunWon: I’m not saying this PEP must adopt following idea, but from experience, defining data structures on the Rust side and generating C headers with cbindgen can be safer than generating Rust code with bindgen. I expect this is a non-starter as the C API is the source of truth and will likely remain so - maybe indefinitely. Jeong, YunWon: All Python functions will end up exposed as extern "C" . For now, I’d actually suggested to consider cbindgen for this: Each module could run cbindgen to produce a C header including all FFI functions with their original comments. Then, maybe clinic tooling could operate directly on those headers without major changes? I’m not totally sure since I don’t fully understand clinic, but it seems it could require less modification than the other 2 suggested methods. This is definitely an interesting approach! I will experiment with it and see how that goes. Jeong, YunWon: we could enforce a policy that every exported symbol must be declared in a properly generated C header. Yeah, I expect this will need to be the case, especially since as mentioned about, the C API is considered the source of truth. Jeong, YunWon: From a build-time perspective, keeping one crate per module as _base64 doing now is very appealing. Yes I think this has a few benefits, such as faster compile times and modularization. Jeong, YunWon: If we hide unsafe behind safe APIs even where true safety can’t be guaranteed, then we lose track of which code must be treated with caution. Absolutely agree here. We probably won’t be able to make everything safe, but being principled about how we interact with unsafe will help significantly. Jeong, YunWon: Shipping strategy: Will the Rust extension only support nogil build? If so, that might help reduce some FFI complexity. I was discussing this with Kirill and we’re thinking Rust modules should be required to support free-threading and sub-interpreters from the start. I don’t think we will have too much difficulty supporting the regular builds if we already support free-threaded. Jeong, YunWon: Python currently ships duplicate C and Python implementations for some modules. If this PEP considers moving some stdlib pieces to Rust, could Rust implementations also coexist as duplicates? I probably would say the Rust implementation should replace the C implementation, as having 3 implementations is rather a lot. But I’d be open to considering the path you propose. I think we’d need good motivation that people will use the in incubation Rust versions if we were to consider that plan. Jeong, YunWon: If this proposal moves forward, I’m ready to dedicate a significant portion of my 2026 open-source time to it. As mentioned, I’m experienced with large-scale Rust FFI using bindgen, and I’m fairly familiar with Python internals as well. Please feel free to poke me if I can help. Finally, I’m genuinely impressed that the CPython community is open to such a bold direction. I’m curious to see how this proposal plays out, and I’ll be following this thread with great interest. Cheers! That’s fantastic to hear! I’ll definitely follow up about that.
