Author: Brett Cannon
Created at: 2025-11-18 00:32
Number: 47
Clean content: I will state upfront I support this endeavour. I was thinking of trying this as a retirement project, so I’m glad Emma and Kirill are trying this much sooner than that! James Gerity: PEP 11’s requirements for each tier’s support are broad enough (language-agnostic enough) that it’s very possible that no changes are required, but I did raise my eyebrows at the intersection with Rust’s own support tiers. As the current maintainer of PEP 11, it won’t require anything and will naturally be assumed that Rust support is a minimum requirement just like C11 support via PEP 7 is an implicit requirement. Steve Dower: I’d rather see people discussing things like how Rust provides any protection/benefit at all when we have to interop everything with “unsafe” C code at a level below anywhere PyO3 could help (which is only safe because it relies on our public C API, which is the safety barrier with guaranteed semantics that can be mapped into Rust’s semantics). So there’s the C code that calls into CPython’s APIs and the C code that stays on your side of things. You’re right that when we only talk about extension modules we are still crossing into the unsafe C code of CPython’s internals, but there’s plenty of code that’s just plain C that you could mess up that never crosses the C API barrier. And if Rust makes inroads into CPython internals then the safety benefits start to go deeper. Steven Sun: Who will lead this large-scale refactoring? Emma and Kirill as the PEP authors along with any other core devs and folks who want to get involved and have appropriate Rust experience. Steven Sun: Who will be responsible for designing the overall code architecture? Who will be making final decisions (for example, how will conflicts with the existing C implementation be resolved)? How can we ensure a stable core team will be able to contribute continuously to this long-term development effort? Is there a communication plan to ensure that progress, challenges, and design changes are transparently communicated to the entire community? How are the project’s key milestones planned? At what point in time or under what circumstances should we reassess the feasibility of these milestones or the overall direction of the project? I don’t think these are really pertinent as they are things we deal with everyday already on the core team in general. Even knowing when to assess success will come down to the SC making a call. Donghee Na: I believe the CPython core team already maintains the C codebase as safely as possible, so while language level safety would certainly be beneficial, the current situation is not one where we are struggling or suffering. I agree, but a “C codebase as safely as possible” is still less safe than a code base in Rust. And now that we have a decade-old systems language that’s safer than C, I think it behooves us to at least try and see if we can make it work.
