Author: James Gerity
Created at: 2025-11-17 20:54
Number: 24
Clean content: Thank you for addressing unsupported platforms where CPython can build/run today that would become untenable under this proposal, it’s an important thing to talk about up-front. emmatyping: CPython has historically encountered numerous bugs and crashes due to invalid memory accesses.We believe that introducing Rust into CPython would reduce the number of such issues by disallowing invalid memory accesses by construction. I think it’s worth being more explicit about this. I understand the general point, but having references to some recent issues that would have been avoided would strengthen the value proposition of the proposal. Obviously any extension modules written in Rust will require knowledge of Rust to contribute to. Since this proposal is looking towards using Rust in the core as well, I think it may be harmful to frame this point in terms of extension modules specifically. ”What will we do about doubling the number of programming languages in the core” feels important to address up-front. Some other questions that occur to me: It seems to me that an eventual PEP should address ”Why not put that development effort towards RustPython ?” in the Rejected Ideas section Does the interaction between PEP 11 support tiers and Rust support tiers merit adjustment of CPython ’s policy? Having 2 additional dimensions to keep track of feels complicated. The idea makes me nervous, but I am well outside the core team, so it’s possible I am not familiar enough with problems this would resolve. I do see the merit in general, especially for the part of this proposal targeting extension modules specifically. Doubling the tooling required to build CPython seems like a bad trade from where I’m standing, but maybe I am underappreciating the value-add. It feels a little big for a single PEP, unless the ideas for integration in the core are “over the horizon” and the eventual PEP would be just about allowing this for extension modules.
