ID: 277474
Author: Emma Smith
Created at: 2025-11-17T16:14:10.092Z
Number: 1
Clean content: Introduction We ( @emmatyping , @eclips4 ) propose introducing the Rust programming language to CPython. Rust will initially only be allowed for writing optional extension modules, but eventually will become a required dependency of CPython and allowed to be used throughout the CPython code base (see update here about requiring Rust ). Motivation Rust has established itself as a popular, memory-safe systems programming language in use by a large number of projects. Memory safety is a property of a programming language which disallows out-of-bounds reads and writes to memory, as well as use-after-free errors. Rust’s safety properties are enforced by an ownership mode for code, which ensures that memory accesses are valid. Rust’s memory safety guarantees have been formally proven by the RustBelt project for code that does not use “unsafe” . By adopting Rust, entire classes of bugs, crashes, and security vulnerabilities can be eliminated from code. Due to Rust’s ownership model, the language also enforces thread safety: data races are prevented at compile time. With free-threaded Python becoming officially supported and more popular, ensuring the standard library is thread safe becomes critical. Rust’s strong thread safety guarantees would ease reasoning around multi-threaded code in the CPython code base. Large C/C++ based projects such as the Linux kernel , Android , Firefox , and many others have begun adopting Rust to improve memory safety, and some are already reporting positive results from this approach . Furthermore, Rust has become a popular language for writing 3rd-party extension modules for Python. At the 2025 Language Summit, it was mentioned that 25-33% of 3rd-party Python extension modules use Rust, especially new extension modules . By adopting Rust in CPython itself, we expect to encourage new contributors to extension modules. 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. While there will necessarily be some unsafe operations interacting with CPython’s C API to begin with, implementing the core module logic in safe Rust would greatly reduce the amount of code which could potentially be unsafe. Rust also provides “zero-cost”, well designed implementations of common data structures such as Vectors, HashMaps, Mutexes, and more. Zero cost in this context means that these data structures allow implementations to use higher-level constructs with the performance of hand-rolled implementations in other languages. The documentation for the Rust standard library covers these data structures very thoroughly. By having these zero-cost, high-level abstractions we expect Rust will make it easier to implement performance-sensitive portions of CPython. Rust additionally enables principled meta-programming through its macro system. Rust has two types of macros: declarative and procedural. Declarative macros in Rust are hygienic, meaning that they cannot unintentionally capture variables, unlike in C. This means it is much easier to reason about macros in Rust compared to C. Procedural macros are a way to write Rust code which does token transformations on structure definitions, functions, and more. Procedural macros are very powerful, and are used by PyO3 to ergonomically handle things like argument parsing, class definitions, and module definitions. Finally, Rust has an excellent build system. Rust uses the Cargo package manager , which handles acquiring dependencies and invoking rustc (the Rust compiler driver). Cargo supports vendoring dependencies out of the box, so that any Rust dependencies do not need to be downloaded (see open questions about dependencies). Furthermore, Rust has easy to set up cross-compilation which only requires installing the desired target and ensuring the proper linker is available. In summary, Rust provides many extremely useful benefits that would improve CPython development. Increasing memory safety would be a significant improvement in of itself, but it is far from the only benefit Rust provides. Implementation The integration of Rust would begin by adding Rust-based extension modules to the “Modules/” directory, which contains the C extensions for the Python standard library. The Rust modules would be optional at build time, dependent on if the build environment has Rust available. Integrating Rust with the CPython C API requires foreign function interface (FFI) definitions in Rust to describe the APIs available. A new crate (a library in Rust terminology) cpython-sys will be introduced to handle these FFI definitions. To automate the process of generating Rust FFI bindings, we use bindgen . Bindgen is not only an official Rust project, but also used ubiquitously throughout the Rust ecosystem to bind to C APIs, including in the Linux and Android projects. Bindgen uses libclang at build time to read C headers and automatically generate Rust FFI bindings for the current target. Unfortunately, due to the use of C macros to define some constants and methods, the cpython-sys crate will also need to replicate a few important APIs like PYOBJECT_HEAD_INIT manually. However these should all be straightforward to replicate and few in number. With the C API bindings available in Rust, contributors can call the FFI definitions to interact with CPython. This will necessarily introduce some unsafe Rust code. However extension modules should be written such that there is a minimal amount of unsafe at the edges of FFI boundaries. Eventually safe abstractions to simplify and standardize code like module definitions, function argument parsing, and class definitions could be adopted to reduce the amount of raw FFI code written. A reference implementation which includes a proof-of-concept _base64 module which uses Rust to provide a speedup to base64 is available. Distribution Rust supports all platforms which CPython supports and many more as well . Rust’s tiers are slightly different, and include information on whether host tools (such as rustc and cargo ) are provided. Here are all of the PEP 11 platforms and their corresponding tiers for Rust: Platform Python Tier Rust Tier aarch64-apple-darwin 1 1 with Host Tools aarch64-unknown-linux-gnu (gcc, glibc) 1 1 with Host Tools i686-pc-windows-msvc 1 1 with Host Tools x86_64-pc-windows-msvc 1 1 with Host Tools x86_64-unknown-linux-gnu (gcc, glibc) 1 1 with Host Tools aarch64-unknown-linux-gnu (clang, glibc) 2 1 with Host Tools wasm32-unknown-wasip1 2 2 without Host Tools x86_64-apple-darwin 2 2 with Host Tools x86_64-unknown-linux-gnu (clang, glibc) 2 1 with Host Tools aarch64-linux-android 3 2 without Host Tools aarch64-pc-windows-msvc 3 1 with Host Tools arm64-apple-ios 3 2 without Host Tools arm64-apple-ios-simulator 3 2 without Host Tools armv7l-unknown-linux-gnueabihf (Raspberry Pi, gcc) 3 2 with Host Tools aarch64-unknown-linux-gnu (Raspberry Pi, gcc) 3 1 with Host Tools powerpc64le-unknown-linux-gnu 3 2 with Host Tools s390x-unknown-linux-gnu 3 2 with Host Tools wasm32-unknown-emscripten 3 2 without Host Tools x86_64-linux-android 3 2 without Host Tools x86_64-unknown-freebsd 3 2 with Host Tools In summary, every platform Python supports is supported Rust at tier 2 or higher, and host tools are provided for every platform other than those where Python is already cross-compiled (e.g. WASI and mobile platforms). Rejected Ideas Use PyO3 in CPython While CPython could depend on PyO3 for safe abstractions over CPython C APIs, this may not provide the flexibility desired. If a new API is added to the C API, it would need to be added to PyO3, then the version of PyO3 would need to be updated in CPython. This is a lot of overhead and would slow down development. Using bindgen, new APIs are automatically exposed to Rust. Keep Rust Always-Optional Rust could provide many benefits to the development of CPython such as increased memory safety, increased thread safety, and zero-cost data structures. It would be a shame if these benefits were unavailable to the core interpreter implementation permanently. Open Questions How should we manage dependencies? By default cargo will download dependencies which aren’t already cached locally when cargo build is invoked, but perhaps we should vendor these? Cargo has built-in support for vendoring code. We could also cargo fetch to download dependencies at any other part of the build process (such as when running configure). How to handle binding Rust code to CPython’s C API? The MVP currently uses bindgen, which requires libclang at build time and a number of other dependencies. We could pre-generate the bindings for all supported platforms, which would remove the build-time requirement on vendoring bindgen and all of its dependencies (including libclang) for those platforms. When should Rust be allowed in non-optional parts of CPython? This section is out of date, please see Pre-PEP: Rust for CPython - #117 by emmatyping . Leaving the original for the record. Given the numerous advantages Rust provides, it would be advantageous to eventually introduce Rust into the core part of CPython, such as the Python string hasher, SipHash. However, requiring Rust is a significant new platform requirement. Therefore, we propose a timeline of: In Python 3.15, ./configure will start emitting warnings if Rust is not available in the environment. Optional extension modules may start using Rust In Python 3.16, ./configure will fail if Rust is not available in the environment unless --with-rust=no is passed. This will ensure users are aware of the requirement of Rust on their platform in the next release In Python 3.17, Python may require Rust to build We choose this timeline as it gives users several years to ensure that their platform has Rust available (most should) or otherwise plan for the migration. It also ensures that users are aware of the upcoming requirement. We hope to balance allowing time to migrate to Rust with ensuring that Rust can be adopted swiftly for its many benefits. How to handle bootstrapping Rust and CPython Making Rust a dependency of CPython would introduce a bootstrapping problem: Rust depends on Python to bootstrap its compiler . There are several workarounds to this: Rust could always ensure their bootstrap script is compatible with older versions of Python. Then the process is to build an older version of Python, build Rust, then build a newer version of CPython. The bootstrap script is currently compatible with Python 2, so this seems likely to continue to be the case Rust could use PyPy to bootstrap Rust could drop their usage of Python in the bootstrap process I ( @emmatyping ) plan to reach out to the Rust core team and ask what their thoughts are on this issue. What about platforms that don’t support Rust? Rust supports all platforms enumerated in PEP 11, but people run Python on other operating systems and architectures. Reviewing all of the issues labeled OS-unsupported in the CPython issue tracker, we found only a few cases where Rust would not be available: HPPA/PA-RISC: This is an old architecture from HP with the last released hardware coming out in 2005 and a community of users maintaining a Linux fork. There is no LLVM support for this architecture. RISC OS: This is a community maintained version of an operating system created by Acorn Computers. There’s no support in Rust for this OS. PowerPPC OS X: This older OS/architecture combination has a community of users running on PowerBooks and similar. There is no support in Rust for this OS/architecture combination, but Rust has PowerPC support for Linux. CentOS 6: Rust requires glibc 2.17+, which is only available in Centos 7. However, it is unlikely users on a no-longer-supported Linux distribution will want the latest version of CPython. Even if they do, CPython would have a hard time supporting these platforms anyway. How should current CPython contributors learn/engage with Rust portions of the code base? Current contributors may need to interact with the Rust bindings if they modify any C APIs, including internal APIs. This process can be well covered in the devguide, and there are many great resources to learn Rust itself. The Rust book provides a thorough introduction to the Rust programming language. There are many other resources in addition, such as Rust for C++ programmers and the official learning resources Learn Rust - Rust Programming Language . To ease this process, we can introduce a Rust experts team on GitHub who can be pinged on issues to answer questions about interacting with the API bindings. Furthermore, we can add a Rust tutorial focused on Rust’s usage in CPython to the devguide. Obviously any extension modules written in Rust will require knowledge of Rust to contribute to. What about Argument Clinic? Argument Clinic is a great tool that simplifies the work of anyone writing C functions that require argument processing. We see two possible approaches for implementing it in Rust: Adapt the existing Argument Clinic to parse Rust comments using the same DSL as in C extensions, and generate Rust function signatures. Create a Rust procedural macro capable of parsing a similar DSL. This approach might allow it to be used by any third-party package, whereas the C-based Argument Clinic does not guarantee compatibility with third-party extensions. Using a proc macro would allow for better IDE integration and could become useful to 3rd party extension authors. Should the CPython Rust crates be supported for 3rd-party use? Should there be a Rust API? Having canonical Rust crates for bindings to CPython’s C API would be advantageous, but the project is ill-prepared to support usage by 3rd-parties at this time. Thus we propose deferring making Rust code supported for 3rd-party use until a later date.
ID: 277475
Author: Cornelius Krupp
Created at: 2025-11-17T16:25:13.623Z
Number: 2
Clean content: Isn’t the experience in the linux kernel with adding rust support as a core part more a cautionary tale? At least it looks that way from the outside. There is constant friction between the two different “types of programmers”, causing a lot of quite public disagreement. If rust becomes a requirement for core devs, might that scare away some current maintainers who don’t want to deal with it?
ID: 277478
Author: Kirill Podoprigora
Created at: 2025-11-17T16:32:54.743Z
Number: 3
Clean content: Hello, and thanks for your question! We will try to make this transition as smooth as possible. We’re planning to write a “migration guide” for CPython contributors to help make their adoption of Rust as easy as possible. Can this scare current maintainers? Yes. Will we do everything we can to make sure it doesn’t? Absolutely.
ID: 277480
Author: Jacopo Abramo
Created at: 2025-11-17T16:45:22.507Z
Number: 4
Clean content: I’m not a core dev nor expert in the internals of CPython, but I wanted to chime in to resonate with the question from @MegaIng , pointing out though that it looks to me (as a Python user) that the community in general is more “approachable” in comparison to what happened during the integration of some Rust in the Linux kernel. Out of curiosity, what would this mean for both PyO3 and RustPython ? Have you reached out to the mantainers of the latter for feedback on how to approach this possibility? If so, what’s their opinion? It looks to me like this possible PEP might benefit greatly from their experience (I don’t know if you guys are part of their team, I’m just assuming you’re not but I apologize if that’s incorrect). Also, I’m probably jumping the gun with this question, but since also RustPython seems to be implementing the GIL in a similar fashion, would you expect some challenges in applying PEP 703 efficiently for rust-based extensions? I imagine (or rather, hope) that by the time 3.17 is out that CPython will be completely GIL-less by then. Do you expect that this additional feature will be provided smoothly in Rust extensions as well? Same question applies for the new experimental JIT which should be more stable in future releases. Finally, if I recall rust applications tend to be a bit “bloated” in binary size, although there are some tricks that can be done at compile time to reduce this - what do these tricks imply on performance I have no idea.
ID: 277482
Author: Steve Dower
Created at: 2025-11-17T17:04:41.634Z
Number: 5
Clean content: As a general direction, I’d rather see “optional extension modules” [1] living outside the main repo and brought in later in the build/release process. Presumably such modules have no tight core dependency, or they wouldn’t be able to be optional, and so they should be able to build on pre-release runtimes and work fine with released runtimes (as we expect of 3rd party developers). The bootstrapping position is discussed in the proposed text and determined to be viable. I think this position applies equally well to bootstrapping the modules we theoretically expect people to write that rely on non-core dependencies. Merging in additional modules as part of our release process is fine. Bundling additional sources and optional build steps into the source tarball is fine (if we think that Linux distros will just ignore us when we say “you should include these modules in your Python runtime”). For what it’s worth, I believe that the parts of CPython that directly depend on OpenSSL and Tcl/Tk are also fit for this. So don’t see my position as being about Rust itself [2] - it’s about the direction we should be taking with adding new modules to the core runtime. In short, adding new ways to add new, non-essential modules to the core is counter to the approach we’ve been taking over the last few years. So I’m -1 on adding one. Also optional regular modules. ↩︎ If you want my position about Rust itself, well… it’s not going to help your PEP at all ↩︎
ID: 277483
Author: Alex Gaynor
Created at: 2025-11-17T17:05:59.850Z
Number: 6
Clean content: As I think many folks know, I’ve been quite involved in these sorts of efforts (starting the effort that became Rust for Linux at the PyCon sprints, migrating pyca/cryptography to Rust, and helping to maintain pyo3). As a result, it will come to no one’s surprise that I’m very supportive of this pre-PEP I’m happy to answer any questions folks have about those experiences and lessons learned.
ID: 277485
Author: James Webber
Created at: 2025-11-17T17:17:51.836Z
Number: 7
Clean content: As a Rust fan I think this is super cool! I do wonder if this is too much to figure out in one PEP, when parts of it seems pretty easily separable. I can see how the overall vision fits together, but it’s a lot. Would it make sense to restrict the initial proposal as just “create the cpython-sys crate and allow optional Rust extensions in the stdlib”? That would allow iteration on making a good generic interface [1] without requiring the SC to make a decision on the long-term plan. there is plenty of prior art in PyO3 , and I think the HPy project has some relevance there too ↩︎
ID: 277487
Author: Michael H
Created at: 2025-11-17T17:31:19.898Z
Number: 8
Clean content: I would feel more comfortable with this if it was dependent on custom json targets stabilizing in Rust. Right now, targetting platforms that Rust itself doesn’t support still requires nightly, and python is used to bootstrap a lot of things in a lot of places. I don’t think the impact of this is going to be reasonably predictable, and I’d want there to be a stable upstream escape hatch for those in unusual situations.
ID: 277489
Author: Gundarin Roman
Created at: 2025-11-17T18:17:44.410Z
Number: 9
Clean content: Doesn’t “C“ in the name of “CPython“ means “C programming language”? If so, shouldn’t the project be eventually renamed when a significant part of it is (re)written in Rust? /joke, but who knows
ID: 277490
Author: Da Woods
Created at: 2025-11-17T18:38:53.354Z
Number: 10
Clean content: I’ll start by saying my opinion doesn’t matter here: the number of lines of C I’ve written that’s in the Python interpreter is of the order of 10, so whatever you decide it’s unlikely to be my personal problem. I’m pretty convinced of Rust as a nice language to write cool new things in (and of the value of exposing cool those cool new things to be used from Python). I’m less convinced of the benefit of rewriting existing working things in Rust. [1] So from my point of view this PEP doesn’t offer a lot - it’s largely proposing “rewrite some modules in Rust with a view to soften people up to rewrite more in Rust”. I’d be much more convinced by a PEP that wanted to add something useful to the standard library and had found the best way to do that was to use a Rust library. Minor comment: emmatyping: Rust could use PyPy to bootstrap I suspect this isn’t viable for a couple for reasons: PyPy isn’t hugely well maintained right now, and (I believe) PyPy needs a Python interpreter to bootstrap itself so may not solve the problem. And I think some of the push-pack Rust gets is from when people do this. It’s hard to argue with the benefit of a new and exciting feature but easy to be unimpressed with “what we already have but in Rust”. ↩︎
ID: 277491
Author: Antoine Pitrou
Created at: 2025-11-17T18:48:33.079Z
Number: 11
Clean content: Emma Smith: Eventually safe abstractions to simplify and standardize code like module definitions, function argument parsing, and class definitions could be adopted to reduce the amount of raw FFI code written. A reference implementation which includes a proof-of-concept _base64 module which uses Rust to provide a speedup to base64 is available. This example shows that you really want the safe abstractions for this to be useful. Otherwise you’re doing the same kind of tedious, unsafe, error-prone low-level pointer juggling and manual reference cleanup as in C (hello Py_DecRef ).
ID: 277493
Author: Guido van Rossum
Created at: 2025-11-17T19:06:36.769Z
Number: 12
Clean content: Snarky note: do we eventually have to rename CPython to CRPython? Seriously, I think this is a great development. We all know that a full rewrite in Rust won’t work, but starting to introduce Rust initially for less-essential components, and then gradually letting it take over more essential components sounds like a good plan. I trust Emma and others to do a great job of guiding the discussion over the exact shape that the plan and the implementation should take.
ID: 277494
Author: Nathan Goldbaum
Created at: 2025-11-17T19:13:14.690Z
Number: 13
Clean content: As a PyO3 maintainer IMO it’d be really nice if we could get rid of the need for the pyo3-ffi crate and instead rely on bindgen bindings maintained by upstream. Most of the overhead of supporting new Python versions is updating the FFI bindings. I bet @davidhewitt has opinions about this from the PyO3 maintainer perspective and I’ll defer to him if he disagrees with me about pyo3-ffi .
ID: 277495
Author: Ed Page
Created at: 2025-11-17T19:18:19.754Z
Number: 14
Clean content: emmatyping: How to handle bootstrapping Rust and CPython Making Rust a dependency of CPython would introduce a bootstrapping problem: Rust depends on Python to bootstrap its compiler . There are several workarounds to this: Rust could always ensure their bootstrap script is compatible with older versions of Python. Then the process is to build an older version of Python, build Rust, then build a newer version of CPython. The bootstrap script is currently compatible with Python 2, so this seems likely to continue to be the case Rust could use PyPy to bootstrap Rust could drop their usage of Python in the bootstrap process I ( @emmatyping ) plan to reach out to the Rust core team and ask what their thoughts are on this issue. The specific team involved is T-bootstrap which you can reach out to on zulip at #t-infra/bootstrap
ID: 277496
Author: Chris Angelico
Created at: 2025-11-17T19:18:26.061Z
Number: 15
Clean content: Guido van Rossum: Snarky note: do we eventually have to rename CPython to CRPython? I would strongly advise against that, on account of people inserting an “A” into it More seriously though: Rust has been a focus for a lot of controversy and risk, with massive open questions such as the impact of a potential Ken Thompson style compiler hack . Will CPython lose trust by becoming dependent on a single specific compiler that might be subject to such a hack? Currently, CPython can be compiled using multiple different compilers (I believe gcc, clang, and MSVC are all supported - correct me if I’m wrong?), which mitigates the threat by allowing them to check each other. Adding Rust to the mix will mean that, on every platform, the same Rust compiler MUST be used.
ID: 277497
Author: Paul Ganssle
Created at: 2025-11-17T19:41:22.635Z
Number: 16
Clean content: I have long liked the idea of doing something like this, and as someone who always introduces memory leaks and segfaults and such any time he writes any kind of C extension code, I welcome the idea of more modern zero-cost abstractions for that [1] . However, one cost I think that has not been mentioned here is the effect that this could have on build times. In my experience, compile times for Rust (and C++) are much slower than for C. On my 2019 Thinkpad T480, from a fresh clone of CPython, I can build the whole thing in 2m50s (with make -j , and admittedly it taxes the machine): real	2m50.573s
user	14m57.260s
sys	0m42.975s After the initial build, incremental builds are in seconds. Not sure I know of any projects of comparable size and complexity to compare with, does anyone know if (in the extreme — I know this isn’t the plan) we were to re-write CPython in Rust, how the build times would compare? I really think that the fast iteration time and low overhead from the builds is a great feature of our current build system that I would really hate to give up. I guess the question is a dual one: can we write Rust in a way that it will not cause build times to explode and if we cannot, is the plan to keep the scope of Rust in CPython to a level where building is still very accessible? My thinking is that if build times were 2x slower that would be acceptable if it meant a significant reduction in security critical bugs, but I personally wouldn’t love it if it were much slower than that. On rereading, I realized that this makes it sound like I want zero-cost abstractions to help me introduce more segfaults. If it’s unclear to anyone, I meant “to avoid that”. I have left the original wording because I like to at least initially convey that I am Chaotic Neutral. ↩︎
ID: 277499
Author: Barry Warsaw
Created at: 2025-11-17T19:51:57.260Z
Number: 17
Clean content: Guido van Rossum: Snarky note: do we eventually have to rename CPython to CRPython? Clearly it should be “CrustyPython” But seriously, I’m really excited about this proposal.
ID: 277500
Author: James Webber
Created at: 2025-11-17T19:55:18.227Z
Number: 18
Clean content: In my experience incremental Rust builds are also very fast–the initial setup (including downloading and building all the dependencies) can be slow, but it’s able to do fast incremental builds just fine. Also, there’s a big difference between debug and release mode–building in debug mode is way faster. I would be surprised if this impacted iteration time unless you’re trying to rebuild the world every time.
ID: 277502
Author: danny mcClanahan
Created at: 2025-11-17T20:32:02.439Z
Number: 19
Clean content: I recently elected to try learning C++ after an entire professional career of Rust + Python, because I wanted to make a build system that can be bootstrapped in as few jumps as possible (so that it could be invoked from inside other build systems like cargo or pip). Having worked a lot on the pants build tool in python + rust, I have strong feelings about affordances the build system should provide to users—feelings I will try to quell to achieve a productive discussion. The pants build tool has incorporated rust since Twitter’s “moonshot” rewrite from python-only through 2017-2019—I contributed the current iteration of our python-level interface for cacheable+parallelizable build tasks ( Concepts | Pantsbuild ), which uses pyo3 to hook up rust async methods as “intrinsics” which can be interchanged with “async def” coroutines (Stu Hood originally proposed and implemented this approach)—we’ve had this interop since before async was stable and before pyo3 existed. We used rust, so we had to use cargo. Most of a decade later, we haven’t managed to use our own build system (written in rust) to build the rust code at the heart of our system. I claim that one of the major reasons for this failure is that cargo is almost unique among build systems in providing absolutely no structured mechanisms for: (1) communicating with other package build scripts in the same dependency graph (2) communicating with the downstream user who invokes cargo (such as a distro packager, or a github actions pipeline) This failure is especially notable because of the same powerful guarantees cargo ensures for rust-only dependency graphs, as described in OP: Finally, Rust has an excellent build system. Rust uses the Cargo package manager, which handles acquiring dependencies cargo unfortunately has no standard mechanism for declaring dependencies downloaded within a build script so that they can be audited or overwritten, except the excessively restricted (non-transitive) and poorly documented links key in Cargo.toml, which requires that a build script link a native library into the resulting executable. cargo also has no standard conception of a “toolchain”, or even an ABI outside of rustc output. This can and does mean that build scripts will fail because a dependency was built for a slightly different ABI, because again, not only is there no standard interface for downstream build configuration, but there’s not even a standard interface for communicating structured data across build scripts . So rust devs end up doing the natural thing and using somewhere in ~/.cache or ~/.config or elsewhere as undocumented mutable state. I am relatively confident this isn’t an oversimplification, because bootstrapping the rust compiler itself ends up invoking multiple distinct reimplementations of LLVM target triple parsing, added at different times and never synced up. This is because rustc uses cargo, and cargo does not support structured communication across build scripts. I proposed some of how I wanted to help improve this situation to NGI Zero at the end of last year. This C++ system I mentioned at the beginning is a competing approach, which would replace cargo instead of attempting incremental reform. I’m still not sure of the “right” answer to this—and I don’t think fixing cargo should be the purview of this PEP anyway. But I am personally convinced that if CPython were to integrate rust (possibly even just at phase 1, with only external module support), we (CPython and pypa contributors, of which I am only the latter) would necessarily have to figure out a more structured way to thread ABI info through cargo, and potentially even institute a whole structured communication mechanism across the build script dependency graph. I think that will be a lot of hard work and we should prepare for it earlier rather than later . I am very heartened to read in OP that there are steps being taken to interface with the rustc team to express CPython’s bootstrapping+portability requirements. It sounds like we’re on a good trajectory already to consider the above. I would just urge contributors to consider that pants has not solved cargo’s python packaging difficulties in many years and that it may be worth opening up a greater discussion about cargo affordances in order for cargo (not just rustc) to support CPython’s (and consequently pypa’s) needs.
ID: 277503
Author: Alex Gaynor
Created at: 2025-11-17T20:40:32.388Z
Number: 20
Clean content: pganssle: I guess the question is a dual one: can we write Rust in a way that it will not cause build times to explode and if we cannot, is the plan to keep the scope of Rust in CPython to a level where building is still very accessible? The best things we can do to keep Rust build UX good for core devs (and other contributors): Keep a lean dep tree – and be able to rebuild each module individually (lots of parallelism, like we have in C). Have a easy to use flow that uses cargo check , which does type checking but doesn’t actually compile, since that gives you a very fast devloop.
ID: 277504
Author: David Hewitt
Created at: 2025-11-17T20:43:30.183Z
Number: 21
Clean content: Thank you @emmatyping @eclips4 for proposing this (and @ngoldbaum for the ping)! Very excited to see this initiative and as a proponent of Python, Rust, and the two together, eager to be involved. As a longtime PyO3 maintainer I have been thinking about what this might look like for a while. I asked about exactly this kind of possibility at the Language Summit earlier this year to gauge the temperature for anyone wishing to experiment. The response I heard then was that experimentation towards a concrete proposal was welcome (I hadn’t yet found the time to explore myself, so thank you). I have a number of comments so will try to keep each brief for now and we can expand later if needed. emmatyping: [rejected] Use PyO3 in CPython pitrou: This example shows that you really want the safe abstractions for this to be useful. I completely agree with both of these points. Depending on PyO3 as currently implemented within CPython will introduce unwanted friction. PyO3 also supports PyPy and GraalPy, as well as older versions of CPython (currently back to 3.7). Rust for CPython will presumably not need to support anything other than current CPython. At the same time, CPython will need safe higher-level Rust APIs to get the benefit of Rust. PyO3 has a lot of prior art on the high-level APIs (and hard lessons learned); I think the right approach here will be similar to what attrs did for dataclasses - the Rust APIs implemented by CPython can pick the bits that work best. emmatyping: What about platforms that don’t support Rust? gccrs is an alternative implementation of Rust for GCC backend, which is not yet at feature parity but an important target for Rust for Linux. If CPython was using Rust, I would hope that efforts for non-llvm platforms may be helped by this. emmatyping: What about Argument Clinic? PyO3’s proc macros function a lot like argument clinic - we could potentially reuse parts of their design (and/or implementation); PyO3 might eventually even depend upon any implementation owned by CPython. I would recommend this choice as the more idiomatic way to do codegen in Rust. emmatyping: Should the CPython Rust crates be supported for 3rd-party use? Should there be a Rust API? ngoldbaum: As a PyO3 maintainer IMO it’d be really nice if we could get rid of the need for the pyo3-ffi crate and instead rely on bindgen bindings maintained by upstream. Most of the overhead of supporting new Python versions is updating the FFI bindings. I agree with both of these points; we may want some experience before deciding how CPython would want to commit to supporting these crates. At the same time, having a way to consume in-dev CPython versions immediately in PyO3 would really help with iteration speed for the ecosystem. PyO3 has precedent of “experimental” features for things not yet stable, one middle ground might be to allow PyO3 to have an experimental feature which switches out pyo3-ffi ’s curated FFI bindings for the ones generated by CPython. MegaIng: Isn’t the experience in the linux kernel with adding rust support as a core part more a cautionary tale? At least it looks that way from the outside. There are a couple of takeaways from Rust for Linux that I think are most interesting here: Social questions - inevitably not everyone will want to be using \<insert language X here\>  instead of \<insert language Y here\>. Some current maintainers might churn from not wanting Rust, and other new maintainers may be attracted by the appeal of using it. The Python community places a lot of emphasis on inclusivity and I’d hope we would welcome everyone’s opinions as valid even if eventually a decision driven by the majority must be taken. (Not implying here whether the majority is for or against exploring Rust support; that is the purpose of having these discussions, after all.) Technical opening - Rust for Linux has unsurprisingly become a major strategic focus for the language. I would hope that Rust for CPython would have justification for carrying similar weight in the focus of the Rust project should there be friction where Rust (and cargo etc) do not currently meet CPython’s needs.
ID: 277505
Author: Emma Smith
Created at: 2025-11-17T20:50:49.739Z
Number: 22
Clean content: Note: I’m working on replying to everyone but wanted to get some initial replies out, I appreciate patience with this. Cornelius Krupp: Isn’t the experience in the linux kernel with adding rust support as a core part more a cautionary tale? At least it looks that way from the outside. There is constant friction between the two different “types of programmers”, causing a lot of quite public disagreement. I agree with @jacopoabramo on this, I like to think that the Python community will be better about being productive, amicable, and respectful when discussing these issues. So I think the experience will be altogether different. Jacopo Abramo: Out of curiosity, what would this mean for both PyO3 and RustPython ? Have you reached out to the mantainers of the latter for feedback on how to approach this possibility? If so, what’s their opinion? It looks to me like this possible PEP might benefit greatly from their experience (I don’t know if you guys are part of their team, I’m just assuming you’re not but I apologize if that’s incorrect). I reached out to David Hewitt who has now responded in this thread and will contribute to the effort (thank you, David!) . Kirill has reached out to the RustPython team as well! Jacopo Abramo: would you expect some challenges in applying PEP 703 efficiently for rust-based extensions? On the contrary, it should be much less effort as safe Rust is thread-safe due to the borrow checker. There will need to be some support added to handle integrating attached thread states, but it should be relatively easy. Jacopo Abramo: Same question applies for the new experimental JIT which should be more stable in future releases. Sorry, I’m not sure if you are asking if Rust extensions will work with the JIT or if Rust can be used to implement it? For the former they should work without issue. For the latter the JIT currently relies on a custom calling convention which is not yet exposed in Rust (but is being discussed to do so last I checked). I don’t suggest moving this code to Rust until it is reasonable to implement in Rust and the necessary calling convention features are available. Jacopo Abramo: Finally, if I recall rust applications tend to be a bit “bloated” in binary size, although there are some tricks that can be done at compile time to reduce this - what do these tricks imply on performance I have no idea. This is definitely something to be cognizant of, thank you for bringing it up! There are several strategies which will not affect performance, such as abort on panic, which we can explore. We will probably want to abort on panic anyway since unwinding over FFI layers is UB. Steve Dower: As a general direction, I’d rather see “optional extension modules” living outside the main repo and brought in later in the build/release process. Presumably such modules have no tight core dependency, or they wouldn’t be able to be optional, and so they should be able to build on pre-release runtimes and work fine with released runtimes (as we expect of 3rd party developers). I think this is an interesting proposal, but orthogonal to the current one. We hope Rust will eventually become required to build CPython so it can be used to improve the CPython core. I would suggest splitting this off into it’s own thread to discuss it further. Steve Dower: In short, adding new ways to add new, non-essential modules to the core is counter to the approach we’ve been taking over the last few years. So I’m -1 on adding one. Again I think it is important to highlight that this proposal is more than just _base64 , and more than just optional modules. We’d eventually like to make Rust a hard dependency so it can be used to improve the implementation of the Python runtime as well. Alex Gaynor: I’m happy to answer any questions folks have about those experiences and lessons learned. Thanks Alex! We definitely want to approach this carefully and with thought, your expertise will be invaluable! James Webber: As a Rust fan I think this is super cool! I do wonder if this is too much to figure out in one PEP, when parts of it seems pretty easily separable. I can see how the overall vision fits together, but it’s a lot. I think we necessarily need to make a plan for long term adoption so we can figure out when Rust can be a required dependency and ensure we plan ahead in advance well enough for it. I don’t want to get anyone caught by surprise when suddenly they need Rust to build CPython when they don’t expect it. I will say that the final PEP will probably be what you propose plus a timeline to make Rust a required dependency. Iterating on ergonomic APIs for Rust is definitely something I’d be working on if cpython-sys is approved. Michael H: I would feel more comfortable with this if it was dependent on custom json targets stabilizing in Rust. Right now, targetting platforms that Rust itself doesn’t support still requires nightly, and python is used to bootstrap a lot of things in a lot of places. Perhaps then we can ensure that releases build with an older nightly Rust to enable such bootstrapping? I expect these cases to be relatively uncommon - Rust supports a large number of platforms. Da Woods: So from my point of view this PEP doesn’t offer a lot - it’s largely proposing “rewrite some modules in Rust with a view to soften people up to rewrite more in Rust”. I would restate our goal as “slowly introduce Rust to carefully integrate it and make sure we get things right and give people time to adapt to the significant change.” _base64 is chosen as an example as it is easier to implement, easier to understand, and would only affect performance, so is entirely optional. I think there are several existing modules that could see clear benefits from being written in Rust, eventually . Especially for those that interact with untrusted input such as json, it would be a significant improvement security-wise if we implemented them in a memory safe language. But I also don’t want to rush in and cause breakage. These kinds of changes should be done carefully and when well-motivated. Da Woods: emmatyping: Rust could use PyPy to bootstrap I suspect this isn’t viable for a couple for reasons: PyPy isn’t hugely well maintained right now, and (I believe) PyPy needs a Python interpreter to bootstrap itself so may not solve the problem. Good point re PyPy requiring some bootstrap Python itself! I hope that the approach of using an older CPython will be workable. Antoine Pitrou: emmatyping: A reference implementation which includes a proof-of-concept _base64 module which uses Rust to provide a speedup to base64 is available. This example shows that you really want the safe abstractions for this to be useful. Otherwise you’re doing the same kind of tedious, unsafe, error-prone low-level pointer juggling and manual reference cleanup as in C (hello Py_DecRef ). I absolutely agree, safe abstractions over things like argument parsing and module creation make PyO3 a joy to use. I hope we can collaborate with the PyO3 maintainers and provide similarly pleasant abstractions in CPython core. It will certainly be a high priority. I do think even in this simple example there are examples of safe abstractions that provide benefits. Kirill wrote up an abstraction over borrowing a Py_buffer that automatically releases the buffer on drop, so that it is impossible to forget to do that and cause a bug: cpython/Modules/_base64/src/lib.rs at c9deee600d60509c5da6ef538a9b530f7ba12e05 · emmatyping/cpython · GitHub Guido van Rossum: Seriously, I think this is a great development. We all know that a full rewrite in Rust won’t work, but starting to introduce Rust initially for less-essential components, and then gradually letting it take over more essential components sounds like a good plan. I trust Emma and others to do a great job of guiding the discussion over the exact shape that the plan and the implementation should take. Thank you Guido for your trust and words of support, it really means a lot!
ID: 277506
Author: Jubilee
Created at: 2025-11-17T20:51:47.620Z
Number: 23
Clean content: Speaking in a broad way to answer a broad (“depends on many details”) question: In C, the primary compilation unit is each individual file. In Rust, the primary compilation unit is each entire crate. Rust offers many conveniences over C (e.g. not needing to “forward declare” things in various files) that depend on the fact it can treat crates as individual units. As a result, if you were to, for instance, compare the two languages based on “files compiled” but one is a crate, the results may be surprising. But with thoughtful (or just arbitrary) splitting of code, Rust does allow you to keep iterative builds relatively fast, especially if all the code you haven’t changed is in crates upstream of the one you changed. Paying attention to this is especially important for the -sys crates containing bindings, as bindgen essentially involves running a compiler to generate code and thus is not cheap. It’s worth noting that C also enjoys faster compilation with careful management of inclusions and include-guards on repeatedly-included headers. There are many caveats, exceptions, and and-alsos one can attach to what I just said when things get more specific. Some Rust idioms will not make it faster to build something, due to e.g. use of generics or #[inline] that requires multiple downstream instantiations in multiple downstream crates. And of course there’s ongoing work here, such as relink, don’t rebuild , where some of us are attempting to make it so changes to upstream crates only cause rebuilds of downstream crates if the upstream crate actually changed its public API.
ID: 277507
Author: James Gerity
Created at: 2025-11-17T20:54:20.059Z
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.
ID: 277508
Author: Steve Dower
Created at: 2025-11-17T20:55:04.476Z
Number: 25
Clean content: Emma Smith: We’d eventually like to make Rust a hard dependency so it can be used to improve the implementation of the Python runtime as well. Then you force me to factor in my experience in Rust, my experience in mixed-language codebases, and my experience in teams, and come down as a firm -1 on the entire proposal.
ID: 277509
Author: David Hewitt
Created at: 2025-11-17T20:56:39.913Z
Number: 26
Clean content: emmatyping: On the contrary, it should be much less effort as safe Rust is thread-safe due to the borrow checker. There will need to be some support added to handle integrating attached thread states, but it should be relatively easy. I completely agree with this; my experience of updating Rust code based upon PyO3 to support free-threaded Python has been relatively painless. I would even go further and suggest that Rust for CPython may be able to assist with the implementation of free-threaded Python; if there are current stlib extension modules needing to be updated for PEP 703 which lack maintainers, migrating them to Rust may be a way to bring on new maintainers and get them thread-safe at the same time. emmatyping: We will probably want to abort on panic anyway since unwinding over FFI layers is UB. For what it’s worth, PyO3 has a mechanism for carrying panics as Python exceptions through stack frames, but I would agree that for sake of binary size and simplicity, an abort would be good enough (the Rust panic hook could be configured to call into Python’s existing fatal exit machinery).
ID: 277512
Author: Steven Sun
Created at: 2025-11-17T21:07:59.873Z
Number: 27
Clean content: In my previous job, I developed and maintained a large codebase mixing C++, Python, and Rust. I am very familiar with these 3 languages. You can notify me if new Rust code or docs requires review. I support if we can start with some extensions with C/Python fallback. Based on my experience, I want to highlight that certain common practice do not align with Rust. For example, fork() is not usable for many Rust libraries (states may be incorrect after fork). https://stackoverflow.com/questions/60686516/why-cant-i-communicate-with-a-forked-child-process-using-tokio-unixstream
ID: 277513
Author: Dmitry
Created at: 2025-11-17T21:17:46.637Z
Number: 28
Clean content: It’s been such an exciting time for Python lately, with this proposal, lazy imports and frozendicts! Another benefit that you might want to mention in the PEP is how IIUC this would open the door for the possibility of shipping with Python modern Rust-based tooling for dep management, formatting and linting, with all the performance, correctness and community enthusiasm that comes with it.
ID: 277516
Author: Emma Smith
Created at: 2025-11-17T21:38:45.101Z
Number: 29
Clean content: Chris Angelico: More seriously though: Rust has been a focus for a lot of controversy and risk, with massive open questions such as the impact of a potential Ken Thompson style compiler hack . Will CPython lose trust by becoming dependent on a single specific compiler that might be subject to such a hack? I’m not familiar with the risks you speak of. As David Hewitt points out, there is a work in progress implementation using gcc, so while there is currently one compiler, that will not remain the case. Paul Ganssle: I guess the question is a dual one: can we write Rust in a way that it will not cause build times to explode and if we cannot, is the plan to keep the scope of Rust in CPython to a level where building is still very accessible? I mostly will defer to @workingjubilee ’s excellent answer and their expertise. I will add however that build times are dear to my heart, so I think good devguide documentation on setting up a dev environment that is configured for fast incremental builds will go a long way in helping. danny mcClanahan: But I am personally convinced that if CPython were to integrate rust (possibly even just at phase 1, with only external module support), we (CPython and pypa contributors, of which I am only the latter) would necessarily have to figure out a more structured way to thread ABI info through cargo This is a really interesting perspective, thanks Danny! I will say getting cargo to fit into CPython’s current build system was a little tricky. That being said I think the ABI question may be less important until Rust code is exposed to users, which will be after we’ve had a lot of experience working with cargo ourselves and can be planned independently of the initial integration, in collaboration with PyPA. David Hewitt: Very excited to see this initiative and as a proponent of Python, Rust, and the two together, eager to be involved. Very excited to have you join us! We greatly value your expertise on Rust and Python interop. David Hewitt: At the same time, CPython will need safe higher-level Rust APIs to get the benefit of Rust. PyO3 has a lot of prior art on the high-level APIs (and hard lessons learned); I think the right approach here will be similar to what attrs did for dataclasses - the Rust APIs implemented by CPython can pick the bits that work best. This is right along the lines of what I was thinking, so glad we are on the same page David Hewitt: emmatyping: What about platforms that don’t support Rust? gccrs is an alternative implementation of Rust for GCC backend, which is not yet at feature parity but an important target for Rust for Linux. If CPython was using Rust, I would hope that efforts for non-llvm platforms may be helped by this. Excellent point! We should make sure to note this in the PEP. David Hewitt: emmatyping: What about Argument Clinic? PyO3’s proc macros function a lot like argument clinic - we could potentially reuse parts of their design (and/or implementation); PyO3 might eventually even depend upon any implementation owned by CPython. I would recommend this choice as the more idiomatic way to do codegen in Rust. Absolutely, I think this would be a great path forward. I would love if the code could be shared across PyO3 and CPython! David Hewitt: Technical opening - Rust for Linux has unsurprisingly become a major strategic focus for the language. I would hope that Rust for CPython would have justification for carrying similar weight in the focus of the Rust project should there be friction where Rust (and cargo etc) do not currently meet CPython’s needs. Yes, there will likely be a few things upstream that may need some work but probably (hopefully!) less than Linux! James Gerity: 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. If you look at issues labeled type-crash you will see a number of issues, such as Use-after-free due to race between SSLContext.set_alpn_protocols and opening a connection · Issue #141012 · python/cpython · GitHub or heap-buffer-overflow in pycore_interpframe.h _PyFrame_Initialize · Issue #140802 · python/cpython · GitHub or JSON: heap-buffer-overflow in encoder caused by indentation caching · Issue #140750 · python/cpython · GitHub . There are many more. James Gerity: ”What will we do about doubling the number of programming languages in the core” feels important to address up-front. Absolutely, I hope that thorough devguide coverage and good tooling will go a long way in making this experience pleasant. I also think having a team of experts will be useful. James Gerity: It seems to me that an eventual PEP should address ”Why not put that development effort towards RustPython ?” in the Rejected Ideas section Thanks, will add this to the list of rejected ideas to add. I also want to cover other language choices, and a few other things. James Gerity: 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. Hm, what adjustment did you have in mind? Steve Dower: Then you force me to factor in my experience in Rust, my experience in mixed-language codebases, and my experience in teams, and come down as a firm -1 on the entire proposal. I’m sorry to hear that Steve. I’m happy to chat further about your experiences at some point, there are definitely wrong ways of integrating new languages into existing code bases. David Hewitt: For what it’s worth, PyO3 has a mechanism for carrying panics as Python exceptions through stack frames, but I would agree that for sake of binary size and simplicity, an abort would be good enough (the Rust panic hook could be configured to call into Python’s existing fatal exit machinery). That’s good to know! I think we will have to evaluate this (as with many things) and decide based on what our experience finds out. Steven Sun: You can notify me if new Rust code or docs requires review. I support if we can start with some extensions with C/Python fallback. Thanks Steven! It’s been great to see a number of people excited about contributing to CPython in Rust if it were added. Steven Sun: Based on my experience, I want to highlight that certain common practice do not align with Rust. For example, fork() is not usable for many Rust libraries (states may be incorrect after fork). https://stackoverflow.com/questions/60686516/why-cant-i-communicate-with-a-forked-child-process-using-tokio-unixstream fork() + threads is sadness pretty universally, it has been an issue for CPython before, so it’s an issue I’m well aware of. Thanks for bringing it up! Dmitry: Another benefit that you might want to mention in the PEP is how IIUC this would open the door for the possibility of shipping with Python modern Rust-based tooling for dep management, formatting and linting, with all the performance, correctness and community enthusiasm that comes with it. That’s a good point, I’ll make sure to note that in the PEP. I misunderstood this post I think, see my comment below.
ID: 277517
Author: James Gerity
Created at: 2025-11-17T21:41:18.108Z
Number: 30
Clean content: emmatyping: Hm, what adjustment did you have in mind? Nothing in particular. 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.
ID: 277519
Author: Chris Angelico
Created at: 2025-11-17T21:49:50.295Z
Number: 31
Clean content: Emma Smith: Rosuav: More seriously though: Rust has been a focus for a lot of controversy and risk, with massive open questions such as the impact of a potential Ken Thompson style compiler hack . Will CPython lose trust by becoming dependent on a single specific compiler that might be subject to such a hack? I’m not familiar with the risks you speak of. As David Hewitt points out, there is a work in progress implementation using gcc, so while there is currently one compiler, that will not remain the case. The risk, in short, is that rustc could easily include all kinds of code that isn’t obvious to an outside auditor. Ken Thompson demonstrated this using a hack that created a login back door; the same thing could infect a more modern system by secretly downgrading TLS in some way, making it possible for a third party to snoop supposedly-encrypted connections. Perhaps in the future this won’t be as much of a consideration, but that would be then, and this is now. Right now, how can we trust rust? How can we know that a Ken Thompson-style hack hasn’t already been done? How do we ensure that one won’t happen in the future? These are not merely academic questions. Python is a well-trusted language used extensively across the internet; if someone with a strong agenda decided to target it, it would be an absolute catastrophe, not least because of how insidious it would be.
ID: 277520
Author: Kirill Podoprigora
Created at: 2025-11-17T21:52:03.542Z
Number: 32
Clean content: @davidhewitt Hi David, and thank you very much for maintaining pyo3! I have a question that we should probably address in the PEP: Can we integrate MIRI into our workflow? Have you tried using it in pyo3, and what were the results? TL;DR: MIRI is an undefined-behavior detection tool for Rust, so I’m guessing it could be helpful for us
ID: 277525
Author: Paul Moore
Created at: 2025-11-17T22:00:39.369Z
Number: 33
Clean content: Chris Angelico: Right now, how can we trust rust? How can we know that a Ken Thompson-style hack hasn’t already been done? How do we ensure that one won’t happen in the future? These are not merely academic questions. It seems to me that adoption of Rust for various other core system components offers some level of assurance here. While there are still risks, it seems likely that they would be discovered relatively quickly as Rust adoption increases. Particular cases I’m thinking of include: Rust in the Linux kernel The Rust reimplementation of coreutils being adopted for Ubuntu Microsoft including Rust in the Windows kernel While the risk involved in a single compiler implementation remains, the chance of detecting any consequent compromise seems like it’s going to rapidly decrease as projects like the above become more widespread.
ID: 277527
Author: Chris Angelico
Created at: 2025-11-17T22:05:19.866Z
Number: 34
Clean content: Paul Moore: It seems to me that adoption of Rust for various other core system components offers some level of assurance here. While there are still risks, it seems likely that they would be discovered relatively quickly as Rust adoption increases. That means that the potential attack surfaces are many. It doesn’t make the decision right for any other project. To be quite honest, I have these exact same concerns regarding the Rust rewrites elsewhere; but (for example) a Rust-based sudo would require that someone first gain shell access as a non-privileged user, and THEN be able to wield an exploit embedded in sudo. With something that is key to many web sites and other internet-connected services, the attack potential is far more direct. Paul Moore: While the risk involved in a single compiler implementation remains, the chance of detecting any consequent compromise seems like it’s going to rapidly decrease as projects like the above become more widespread. And that would be a strong protection, if the only type of attack were one that hits everything all at once. Unfortunately, as Ken Thompson’s hack proved, this sort of attack can be extremely narrowly targeted. And Python is a juicy target.
ID: 277528
Author: James Webber
Created at: 2025-11-17T22:08:01.407Z
Number: 35
Clean content: Is any language really safe from this? Surely gcc alone is a hugely valuable target for such an attack–how do we know it hasn’t happened? Heck, how do we know it hasn’t happened in CPython ? It seems like this is a separate security discussion that goes far beyond Rust.
ID: 277531
Author: Steven Sun
Created at: 2025-11-17T22:10:45.966Z
Number: 36
Clean content: Rosuav: The risk, in short, is that rustc could easily include all kinds of code that isn’t obvious to an outside auditor. I want to add that this risk is real. Besides the code in rust compiler, Rust support procedural macro which executes user-written code during compilation. It requires a lot of work to fully audit. This happened in Rust community before. One previous event is a well-used library shipping pre-built binary to accelerate procedural macro without notice, causing many worries from users. github.com/serde-rs/serde using serde_derive without precompiled binary opened 11:39PM - 27 Jul 23 UTC closed 03:50PM - 17 Aug 23 UTC decathorpe I'm working on packaging serde for Fedora Linux, and I noticed that recent versi … ons of serde_derive ship a precompiled binary now. This is problematic for us, since we cannot, under *no* circumstances (with only very few exceptions, for firmware or the like), redistribute precompiled binaries.

Right now the fallback I am trying to apply for the short-term is to patch serde_derive/lib.rs to unconditionally include lib_from_source.rs (we don't really care about compilation speed for our non-interactive builds).

I'm wondering, how is the x86_64-unknown-linux-gnu binary actually produced? The workspace layout in this project looks very differently from when I last looked in here ... Would it be possible for us to re-create the binary ourselves so we can actually ship it? Or would it be possible to adapt the serde_derive crate to fall back to the non-precompiled code path if the binary file is missing? Rosuav: how can we trust rust? How about a switch to turn off all rust code?
ID: 277532
Author: Chris Angelico
Created at: 2025-11-17T22:11:36.188Z
Number: 37
Clean content: James Webber: Is any language really safe from this? Surely gcc alone is a hugely valuable target for such an attack–how do we know it hasn’t happened? Heck, how do we know it hasn’t happened in CPython ? The biggest protection is having multiple compilers. Do you want to make sure your gcc hasn’t been infected? Download the source code for gcc, and compile it using clang. This could also be affected, but only if someone has infected BOTH compilers. The more diffferent options there are, the less of a threat this is. The threat is, by definition, only relevant to compiled languages that compile their own compilers. It’s inherent in the bootstrapping. So this can’t happen in CPython as it currently is, unless there’s some way that Python code is being used to generate future versions of the CPython binary, in a way that’s independent of the source code (eg Argument Clinic can’t be that, because the output is right there for everyone to see).
ID: 277534
Author: Steve Dower
Created at: 2025-11-17T22:17:33.902Z
Number: 38
Clean content: I’ll briefly put my security team hat on and say that the security side of this is being way overblown. The risk of a supply-chain attack via the compiler is miniscule compared to the multitude of other options - adding Rust doesn’t make that part worse. 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).
ID: 277536
Author: Emma Smith
Created at: 2025-11-17T22:30:00.207Z
Number: 39
Clean content: Chris Angelico: The biggest protection is having multiple compilers. Do you want to make sure your gcc hasn’t been infected? Download the source code for gcc, and compile it using clang. This could also be affected, but only if someone has infected BOTH compilers. The more diffferent options there are, the less of a threat this is. Given that clang had to be bootstrapped by gcc, I think it is impossible to say that this will work for sure. Steve Dower: I’ll briefly put my security team hat on and say that the security side of this is being way overblown. The risk of a supply-chain attack via the compiler is miniscule compared to the multitude of other options - adding Rust doesn’t make that part worse. Thanks Steve! I appreciate you piping up on this. 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 I have a couple of thoughts on this, and hope @davidhewitt has more since he has thought about this problem probably a lot more than I have First, we can build safe abstractions over unsafe operations which will reduce the amount of unsafe users need to interact with. Furthermore, I expect to start with, a safe core for extension modules can be implemented then exposed to CPython through unsafe FFI procedures. This is an approach that has seen wide success throughout other projects. One of Rust’s strengths is that it allows you to focus on where unsafety occurs. Finally, if more of the interpreter were to become Rust, these portions would presumably have safe Rust interfaces.
ID: 277537
Author: Guido van Rossum
Created at: 2025-11-17T22:31:09.753Z
Number: 40
Clean content: steve.dower: Then you force me to factor in my experience in Rust, my experience in mixed-language codebases, and my experience in teams, and come down as a firm -1 on the entire proposal. Steve, without more details your -1 has no weight. You can’t just argue from authority .
ID: 277538
Author: Aria Desires
Created at: 2025-11-17T22:32:52.963Z
Number: 41
Clean content: 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). I highly recommend reading the article from the Android Security team that the original post linked . In particular, the article focuses on a “near-miss” where they almost shipped one (1) memory safety vulnerability in Rust: This near-miss inevitably raises the question: “If Rust can have memory safety vulnerabilities, then what’s the point?” The point is that the density is drastically lower. So much lower that it represents a major shift in security posture. Based on our near-miss, we can make a conservative estimate. With roughly 5 million lines of Rust in the Android platform and one potential memory safety vulnerability found (and fixed pre-release), our estimated vulnerability density for Rust is 0.2 vuln per 1 million lines (MLOC) Our historical data for C and C++ shows a density of closer to 1,000 memory safety vulnerabilities per MLOC. Our Rust code is currently tracking at a density orders of magnitude lower: a more than 1000x reduction. … The primary security concern regarding Rust generally centers on the approximately 4% of code written within unsafe{} blocks. This subset of Rust has fueled significant speculation, misconceptions, and even theories that unsafe Rust might be more buggy than C. Empirical evidence shows this to be quite wrong. Our data indicates that even a more conservative assumption, that a line of unsafe Rust is as likely to have a bug as a line of C or C++, significantly overestimates the risk of unsafe Rust. We don’t know for sure why this is the case, but there are likely several contributing factors: unsafe{} doesn’t actually disable all or even most of Rust’s safety checks (a common misconception). The practice of encapsulation enables local reasoning about safety invariants. The additional scrutiny that unsafe{} blocks receive. I totally understand the concern but there’s so many big old C(++) projects that have integrated Rust and “safety of the bindings” is an obvious concern everyone has and it just… doesn’t end up being that big of a deal in practice? In practical specific terms, it’s often reported that Rust often makes implicit ownership/lifetime constraints in C APIs explicit and easier to work with. The Rust bindings to C functions can include lifetimes that enforce these contracts (and yes a lot of C APIs map onto lifetimes and ownership well).
ID: 277539
Author: Steve Dower
Created at: 2025-11-17T22:33:10.734Z
Number: 42
Clean content: Guido van Rossum: Steve, without more details your -1 has no weight I’m aware. Happy to chat more with the people interested in driving this forward or evaluating/deciding on it, but there are more than enough opinions here already and I don’t see mine helping drive the discussion forward in any particularly meaningful way (especially given the response to my “keep it contained” concern was “actually, we’re going to make it less contained”).
ID: 277540
Author: William Woodruff
Created at: 2025-11-17T22:34:06.482Z
Number: 43
Clean content: Steven Sun: Besides the code in rust compiler, Rust support procedural macro which executes user-written code during compilation. It requires a lot of work to fully audit. It’s worth noting that Rust’s compile-time code execution (via build.rs ) closely mirrors the style and trust model already assumed by Python packaging (via setup.py ). I’m not extremely familiar with the history of build.rs , but it wouldn’t especially surprise me if setup.py (and Gemfile , etc.) were used as a reference point. (I also think the risk of compile-time code execution in Rust is narrow compared to what already exists: how often do you read the autoconf that your C and C++ dependencies use to codegen shell scripts at build time? We have empirical evidence in the form of xz-utils that attackers find that very appealing!)
ID: 277546
Author: Steven Sun
Created at: 2025-11-17T23:03:19.329Z
Number: 44
Clean content: Still a few important questions: Who will lead this large-scale refactoring? 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?
ID: 277553
Author: Donghee Na
Created at: 2025-11-18T00:01:37.746Z
Number: 45
Clean content: I am basically neutral on adopting Rust, and I think Ruby provides a good reference model. They introduced Rust for their JIT implementation as an optional component, and it is worth studying how they approached. (only using std-lib, except unittest and unittest module are excluded when they release) However, I am cautious about the idea of fully rewriting the CPython codebase in Rust. We have a lot of low level and very optimized C code that Rust cannot express safely. A good example is the computed goto dispatch in the interpreter, which would require a large amount of unsafe code or inline assembly if we tried to reproduce it in Rust. Platform support is also still a concern, and that’s why people are waiting for gcc-rs , because once it is shipped, we can cover over where gcc and clang do. My view is that if we want to move forward, we should begin with an experimental approach. We can start by introducing new, non-essential modules written in Rust and evaluating the results. That feels like a reasonable and safe first step, and it allows us to focus on productivity rather than framing everything around memory safety. 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. From what I understand, the Ruby team adopted Rust mainly because implementing their JIT in Rust was more productive than doing it in C. I think that was one of the major factors behind their choice.
ID: 277554
Author: Jeong, YunWon
Created at: 2025-11-18T00:02:42.657Z
Number: 46
Clean content: People still remember the huge drama from early 2025, but I think we should pay more attention to what Torvalds and Greg K-H recently said at the Open Source Summit Korea just two weeks ago. So, so that’s that’s one thing that has changed for me is that I actually feel like sometimes I need to encourage some of the other maintainers to be more open to to new ideas. If we want to bring up Rust for Linux as an example, we should not only talk about how introducing a new and unfamiliar idea can create conflict among existing maintainers, but also emphasize that leadership plays a role in encouraging the community to embrace such changes.
ID: 277557
Author: Brett Cannon
Created at: 2025-11-18T00:32:57.514Z
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.
ID: 277558
Author: Emma Smith
Created at: 2025-11-18T00:37:14.443Z
Number: 48
Clean content: Brett Cannon: sunmy2019: 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. Brett Cannon: sunmy2019: 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. I agree with everything Brett says above, but also wanted to add that I am going to spend some time over the next few days on community building around Rust in CPython with a goal of kicking off discussions around a lot of the topics brought up here.
ID: 277559
Author: Barry Warsaw
Created at: 2025-11-18T00:45:01.991Z
Number: 49
Clean content: Donghee Na: However, I am cautious about the idea of fully rewriting the CPython codebase in Rust. I would go further and predict that this will never happen, and claim that it shouldn’t be a goal of the Rust-in-Python project.  There are 10**oodles of person-years invested in the CPython core interpreter, and I just don’t see how that will ever be cost effective to rewrite, even as a Ship of Theseus . But that’s not to say we shouldn’t go forward with this experiment, because we’ll better understand the costs and benefits [1] . One of the soft consequences I’m especially interested in is whether this attracts more or fewer core developers contributing to the Rust bits than the C bits.  I don’t remember the numbers, but I vaguely recall some discussion about the number of core devs who are comfortable contributing to the C bits vs the Python bits.  The former is surely a smaller number, and my guess is that even fewer are comfortable in Rust today [2] . and better know the unknown unknowns ↩︎ To be clear, I consider everyone’s contributions, regardless of where or what language, to be incredibly valuable and valued ↩︎
ID: 277560
Author: Emma Smith
Created at: 2025-11-18T00:53:59.811Z
Number: 50
Clean content: Donghee Na: We have a lot of low level and very optimized C code that Rust cannot express safely. A good example is the computed goto dispatch in the interpreter, which would require a large amount of unsafe code or inline assembly if we tried to reproduce it in Rust. I think this is actually a great example where Rust could be a huge improvement over C. There is  interest in the Rust community to implement a safe state machine loop, e.g. this proposal RFC: Improved State Machine Codegen by folkertdev · Pull Request #3720 · rust-lang/rfcs · GitHub . That proposal may not get into Rust, but given the interest I am sure there will be some safe solution implemented eventually. And I would like to re-iterate another point: we absolutely should not re-write things that don’t make sense to. The core interpreter loop itself may not make sense to for a while, but that doesn’t mean other important runtime things can’t be Rust, like thread state management, the parser, and others. Barry Warsaw: I would go further and predict that this will never happen, and claim that it shouldn’t be a goal of the Rust-in-Python project. Well then you’ll be really glad with this blurb I was writing in response to Donghee’s post . Speaking for myself here: The goal of this project should not specifically be to re-write CPython in Rust, but rather iteratively move more C code to Rust over time and reap the benefits for those portions of code. This may end up meaning Python becomes entirely Rust! But I don’t think that will necessarily be the end goal. Barry Warsaw: One of the soft consequences I’m especially interested in is whether this attracts more or fewer core developers contributing to the Rust bits than the C bits. I’m also quite interested in this! Given that we have seen people shifting to Rust for new 3rd-party extension modules I really hope that will translate into more contributors.
ID: 277561
Author: Alex Gaynor
Created at: 2025-11-18T00:59:01.064Z
Number: 51
Clean content: emmatyping: The goal of this project should not specifically be to re-write CPython in Rust, but rather iteratively move more C code to Rust over time and reap the benefits for those portions of code. One thing I do think is worth saying: The highest ROI pieces are going to be modules and perhaps builtin types/functions, which can be implemented entirely in safe Rust with ergonomics high level APIs, reaping performance and developer experience/velocity wins. Something like the GC is at the absolute nadir of the value of Rust: it inevitably requires a decent amount of unsafe and won’t benefit from Rust’s other advantages. And then many other things (e.g., the parser or interpreter loop) are likely to be in the middle in terms of where I’d estimate the ROI is.
ID: 277562
Author: Donghee Na
Created at: 2025-11-18T01:15:27.824Z
Number: 52
Clean content: emmatyping: but that doesn’t mean other important runtime things can’t be Rust, brettcannon: 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. Just to clarify: I love using Rust, and I’m one of the people interested in bringing Rust into CPython. I’ve talked about this topic in the context of JIT because of its practical advantages. @emmatyping What I’m curious about is this: in the current PoC, most of the code uses unsafe blocks. I understand this isn’t Rust’s fault but rather a limitation of the CPython API. Still, how do these modules become memory-safe in the PoC, and how much less do we need to worry about memory safety compared to writing the same code in C? For example, if you could say something like “X% of the code in the base64 module becomes memory-safe,” that would be a helpful metric to highlight. Also, do you have any plans to remove the unsafe blocks in modules like base64 ? If so, could you include that plan in the PEP? Another thing: could you compare build times and performance between the C version (with PGO + LTO) and the Rust build? I think that would make the PEP much more balanced and fair for reviewers.
ID: 277563
Author: Neil Schemenauer
Created at: 2025-11-18T01:19:41.409Z
Number: 53
Clean content: Alex Gaynor: Something like the GC is at the absolute nadir of the value of Rust: it inevitably requires a decent amount of unsafe and won’t benefit from Rust’s other advantages. Based on my recent experience in adding hardware prefetch to the free-threaded GC, I feel like writing in Rust could have provided some good benefit.  For example, implementing the gc_span_stack_t data structure and associated methods would have been easier to write and to review.  I would expect that it also would have prevented this memory leak bug in that code.
ID: 277565
Author: Emma Smith
Created at: 2025-11-18T01:47:21.059Z
Number: 54
Clean content: Donghee Na: What I’m curious about is this: in the current PoC, most of the code uses unsafe blocks. I understand this isn’t Rust’s fault but rather a limitation of the CPython API. Still, how do these modules become memory-safe in the PoC, and how much less do we need to worry about memory safety compared to writing the same code in C? I think this section covers that: Emma Smith: Eventually safe abstractions to simplify and standardize code like module definitions, function argument parsing, and class definitions could be adopted to reduce the amount of raw FFI code written. The current implementation is really a proof of concept, so there are a lot of places it could improve. It started with myself wishing to see how hard it would be to integrate Rust with cargo into our existing build system. A Rust _base64 module in CPython will look a bit different from the current proof of concept I hope. I expect extension modules will likely be able to be to be 80% safe hand-written code or more. That being said, building out the safe abstractions will take time and effort to do properly. So I think I would say, if you want to see something like where I hope to end up, look at PyO3, where the vast majority of hand written code is safe. Donghee Na: Another thing: could you compare build times and performance between the C version (with PGO + LTO) and the Rust build? I think that would make the PEP much more balanced and fair for reviewers. @Eclips4 found that his hand-rolled implementation that does not use any SIMD is about 1.6x faster than the _binascii implementation in use today. It’s hard to make a “fair” compilation speed benchmark because there are many variables that can come into play and knobs that can be tuned. The added Rust code will also necessarily add more compile time because we aren’t removing code by introducing _base64 .
ID: 277566
Author: Brénainn Woodsend
Created at: 2025-11-18T01:51:41.667Z
Number: 55
Clean content: Will the binaries written in rust be able to share a single copy of dependencies and/or the rust runtime? My recollection is that ABI in rust is a forgotten dream and that each library/ or executable ends up with separate copy of all its dependencies plus a big fat core runtime lumped into it, turning a network of little libraries [1] into a network of bloatware. But it’s a long time since my last (unsuccessful) attempt to get into rust so that might no longer be true (assuming that it was ever true). or extension modules in CPython’s case ↩︎
ID: 277567
Author: William Woodruff
Created at: 2025-11-18T02:04:28.924Z
Number: 56
Clean content: Brénainn Woodsend: Will the binaries written in rust be able to share a single copy of dependencies and/or the rust runtime? My recollection is that ABI in rust is a forgotten dream Rust has no problem using the C ABI; from experience, the norm when integrating Rust into existing C codebases is retain existing ABI boundaries and perform dynamic linking in the same ways that the codebase would normally. (There’s a separate issue, which is that fully separate Rust builds tend to prefer static linkage because there’s no stable Rust ABI. But the integration efforts of Chrome, Firefox, etc. are good examples of integration of Rust components into projects that assume the C/C++ ABIs.)
ID: 277571
Author: Jeong, YunWon
Created at: 2025-11-18T02:25:14.462Z
Number: 57
Clean content: Hi, I’m one of the RustPython developers, and during work hours I maintain a tightly-coupled C++/Rust project of about 200k lines. I’d like to comment on some of the points raised in the post and the thread. I’m still getting used to Discourse, so please excuse me about missing quotes. Questions about RustPython RustPython isn’t something that can be considered in this PEP in short term. RustPython and CPython are not semantically compatible across many layers of their implementation. Well, RustPython has a bunch of pure Rust library with excellently working Python stdlibs. it could serve as a reference when introducing Rust versions of certain libraries. I don’t believe it is directly related to this PEP. RustPython has its own approach to running without a GIL, but it’s not compatible with CPython’s nogil direction. 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. bindgen I think there must be a good guidelines on how bindgen should be used. bindgen generates both data structure definitions and function bindings. Function bindings are usually reliable—but data structure definitions often are not. If we rely on bindgen for those, we must run the generated tests to verify compatibility. 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’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. Though while rust-in-cpython focuses on writing stdlib modules, where C doesn’t need to call Rust, there may be limited motivation to use cbindgen. This perspective comes from my experience with mixed C++/Rust projects. CPython being a C/Rust project may lead to fewer issues. clinic 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. When Rust penetrates deeper than the module boundary and this approach breaks down, we’ll have better insight for future decisions anyway. ABI I’m not sure how far Rust implementation will expand, but compared to Pants, CPython’s requirements seem much simpler. If we connect this with the clinic/cbindgen idea, we could enforce a policy that every exported symbol must be declared in a properly generated C header. Since the only stable ABI in Rust is the C ABI, having headers fully specify remains reasonable until Rust APIs are officially exposed to users. Build time Ideally, Rust debug builds shouldn’t be too slow. But many Rust libraries lean heavily on proc-macros, which can significantly impact build times. For example, RustPython has far less code and functionality than CPython, yet it takes ~5× longer to build, and the gap is even bigger for incremental builds. If build time is a major concern, guidelines limits unnecessary proc-macro usage may help. Also, on the external tooling side, we can hope llvm might support faster Rust debug builds later since Python is a priority project for llvm project. I don’t worry about generics in rust-in-cpython. Unlike RustPython, rust-in-cpython must generate C interface, which discourage to abuse generics. From a build-time perspective, keeping one crate per module as _base64 doing now is very appealing. Using unsafe In my opinion, completely eliminating unsafe from base64 isn’t the right goal. Rust guarantees that code outside an unsafe {} block is safe. Anything the compiler cannot verify must be wrapped in unsafe {} . Wrapping unsafe internals in a “safe” API means the programmer is manually guaranteeing safety. Some guarantees can be established through review and careful implementation, but FFI safety often cannot be fully guaranteed due to inherent interface limitations. 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. So instead of trying too hard to remove unsafe , it’s better to encourage properly mark actually unsafe code and minimize them when possible. Rust benefits vs. FFI cost Rust reduces memory-related bugs, but across FFI boundaries, things can actually become less safe than using a single C compiler. The more FFI boundaries exist, the more type information is lost, and the more binding risk increases. Usually, early Rust adoption increases FFI surface area and reduce problems in the rust codebase but also creates new problems at the same time. Then over time, as Rust takes over more internals, the boundary shrinks and things feel cleaner again. From that perspective, starting with modules is a positive direction: a lot of code, limited boundaries. Questions Shipping strategy: Will the Rust extension only support nogil build? If so, that might help reduce some FFI complexity. Duplication: 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? If so, a guideline to have different implementations about same feature will be great. Having separate module paths and build flags would allow experimentation, and then flipping Rust on by default once stable. It will be work like a sort of feature-level incubators. If possible, I’d love to see this code used: GitHub - RustPython/pymath (While working on it, I learned how dealing with FMA is way nicer in Rust than in C. Thanks tim-one.) 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!
ID: 277572
Author: Éric Araujo
Created at: 2025-11-18T02:29:28.275Z
Number: 58
Clean content: Hi, Dmitry: this would open the door for the possibility of shipping with Python modern Rust-based tooling for dep management, formatting and linting Can you expand on this with some specific examples? I can only interpret this as a suggestion that Python releases would include uv and ruff, and it doesn’t make much sense to me. These projects already exist, their adoption does not depend on CPython using Rust itself. And formatters and linters are third-party projects, not developed by python-dev, and chosen by developers. One thing with special status is pip, included via ensurepip, to solve the packaging boostrapping issue.
ID: 277579
Author: Emma Smith
Created at: 2025-11-18T04:11:33.057Z
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.
ID: 277580
Author: Emma Smith
Created at: 2025-11-18T04:13:55.112Z
Number: 60
Clean content: Éric Araujo: monk-time: this would open the door for the possibility of shipping with Python modern Rust-based tooling for dep management, formatting and linting Can you expand on this with some specific examples? I can only interpret this as a suggestion that Python releases would include uv and ruff, and it doesn’t make much sense to me. Yeah on a re-read I think my earlier comment misinterpreted this message as discussing clippy and rustfmt (Rust tools). So I would say adding Python tooling that is written in Rust to CPython is out of scope for this proposal.
ID: 277581
Author: Raphael Gaschignard
Created at: 2025-11-18T04:22:28.658Z
Number: 61
Clean content: corona10: @emmatyping What I’m curious about is this: in the current PoC, most of the code uses unsafe blocks. I understand this isn’t Rust’s fault but rather a limitation of the CPython API. Still, how do these modules become memory-safe in the PoC, and how much less do we need to worry about memory safety compared to writing the same code in C? For example, if you could say something like “X% of the code in the base64 module becomes memory-safe,” that would be a helpful metric to highlight. To expand on this point, I see Rust as a potential usability gain here, much more than the security aspect. I think the argument to use Rust for CPython here would be much stronger if we could see standard_b64encode implemented in a way that takes advantage of Rust’s RAII to reduce the book-keeping we have to do in the C code right now. Without a “Rust API” here for writing these extensions, this becomes purely a security argument (that I find fairly unconvincing at some level). If standard_b64encode was returning a Result and we were able to use ? and all this other stuff with a wrapper that did “the right thing” that would be, at least to me, much more interesting EDIT: though a point against this being easy might be the memory allocation story here… though the error allocation failure paths are about allocation failures in the Python arena, not sure if that means we really have no stack left over. Still think it’s worth proving the point that this has ergonomics improvements, because that feels like a pretty big deal all things considered!
ID: 277583
Author: Emma Smith
Created at: 2025-11-18T04:40:03.220Z
Number: 62
Clean content: Raphael Gaschignard: I think the argument to use Rust for CPython here would be much stronger if we could see standard_b64encode implemented in a way that takes advantage of Rust’s RAII to reduce the book-keeping we have to do in the C code right now. Without a “Rust API” here for writing these extensions, this becomes purely a security argument (that I find fairly unconvincing at some level). If standard_b64encode was returning a Result and we were able to use ? and all this other stuff with a wrapper that did “the right thing” that would be, at least to me, much more interesting One example of reducing mental bookkeeping is the BorrowedBuffer abstraction in the implementation cpython/Modules/_base64/src/lib.rs at c9deee600d60509c5da6ef538a9b530f7ba12e05 · emmatyping/cpython · GitHub . As mentioned previously, the current example is pretty bare-bones as it is a proof of concept. There is a large room for improvement in ergonomics. But even with raw FFI bindings, it’s possible to have a safe, idiomatic Rust core of an extension module then expose that via unsafe wrappers. And I think even that will improve the safety and utility of writing extensions in CPython.
ID: 277590
Author: Raphael Gaschignard
Created at: 2025-11-18T04:56:49.874Z
Number: 63
Clean content: Yeah I think the BorrowedBuffer is a good example of helping a bit with its Drop . I guess this would be more convincing to me (random person who has little stake in this beyond poking in CPython internals from time to time but wants to see some idea of this succeed!) if we go a bit further in the barebones interpretation to prove some idea of improved ergonomics, focused entirely on this encode implementation, which includes just enough bookkeeping futzing that would be nice to not see anymore: let result = unsafe {
        PyBytes_FromStringAndSize(ptr::null(), output_len as Py_ssize_t)
    };
    if result.is_null() {
        return ptr::null_mut();
    } instead being something like: let Ok(result) = PyBytes::from_string_and_size(ptr::null(), output_len as Py_ssize_t) else { return ptr::null_mut() } ; Or even, if there’s some way to make PyResult -y thing that could collapse the common CPython errors nicely (maybe not a possible thing!): let result = PyBytes::uninit_from_size(output_len)? Just like BorrowedBuffer , it feels like there could be some single-field wrapper structs, and smart constructors that could operate in a “Rust API”-y level to work off of results Similarly in: let dest_ptr = unsafe { PyBytes_AsString(result) };
if dest_ptr.is_null() {
    unsafe {
        Py_DecRef(result);
    }
    return ptr::null_mut();
} I would have expected we could have some Rust-y wrapper on references that would give us that Py_DecRef call for free just through RAII. And maybe I’m too optimistic of Rust’s compiler toolchain, but if the wrapper was a single field struct, my impression is we would be able to get that for free. The thing I would assume is that within the extension module we could go full Rust API goodness, and it’s only really at the entry and exit points that one would need to go back to acknowledging CPython’s realities a bit more. Anyways yeah, I’m very curious what the ‘pie in the sky most of the APIs used in the encoding example have a nice API’ version of the encode port looks like, because jumping from C to Rust could make the maintenance barrier seem way lower. We don’t have to port everything, just enough and enough smoke and mirrors to say “this is what it looks like in practice for this one method”. Because right now beyond the platform support tradeoffs etc, the PoC example is also presenting as generally more code, not less. In my mind’s eye we wouldn’t even have a tradeoff here, and the code would be simpler.
ID: 277593
Author: Emma Smith
Created at: 2025-11-18T05:05:28.705Z
Number: 64
Clean content: Interactions between Python objects and borrows is rather complicated. I don’t think this thread is a great place to go over detailed API design discussion as that isn’t the goal of the PEP, but I’d be happy to chat in another forum like the Python Discord or via DM. I will say a pie-in-the-sky API will look somewhat like an implementation using PyO3 . I can write up such an implementation and share that if people think it would informative.
ID: 277594
Author: Dan
Created at: 2025-11-18T05:09:12.306Z
Number: 65
Clean content: but eventually will become a required dependency of CPython What does this mean for projects that embed CPython inside their C++ projects? Boost::python or pybind11?
ID: 277596
Author: Emma Smith
Created at: 2025-11-18T05:18:14.327Z
Number: 66
Clean content: You would need Rust to build any Rust extension modules you want in your embedded Python. I believe most embedding links to libpython so that would already be built and wouldn’t require Rust.
ID: 277597
Author: Dan
Created at: 2025-11-18T05:26:57.004Z
Number: 67
Clean content: Emma Smith: You would need Rust to build any Rust extension modules you Thank you, I know nothing of Rust, I see the word ‘dependency’ and I immediately get scared. Python and all the 3rd party modules must load into the host application’s process. In my case, I’m running Python inside AutoCAD for windows. If this is optional, or something that’s not going load some sort of runtime, or something that could cause issues, then great
ID: 277598
Author: Dmitry
Created at: 2025-11-18T05:40:40.383Z
Number: 68
Clean content: Éric Araujo: Can you expand on this with some specific examples? I can only interpret this as a suggestion that Python releases would include uv and ruff, and it doesn’t make much sense to me. We do already ship with pip and pymanager, and there’s no denying that Rust/Go have created an expectation for modern languages to include quality standard dev tooling. And it is equally apparent that the best Python tooling for the next decade will be written in Rust [1] . So I don’t see a future where Python also ships with such tools as outside the realm of possibility [2] . So I don’t see why not. This is clearly out of scope for this proposal, which is why I framed it only as a future possibility – one that would require its own difficult discussion and the platform/build support this PEP addresses. So I won’t pursue this further here. regardless of if it’s still Astral tools like uv and ruff (or ty when it reaches stable) or something else like pyrefly ↩︎ I do believe replacing pip with uv might just be the most widely applauded move Python can make ↩︎
ID: 277601
Author: Jeong, YunWon
Created at: 2025-11-18T07:32:25.879Z
Number: 69
Clean content: To achieve good ergonomics, we’ll need not only cpython-sys but also another crate built on top of it that provides proper Rust abstractions. (Following naming conventions, it would be called cpython , but that name is already taken.) Right now, the PEP only covers cpython-sys , but if we expect Rust ergonomics by this PEP, I think some consideration of this additional crate should also be included.
ID: 277602
Author: Michał Górny
Created at: 2025-11-18T07:39:20.436Z
Number: 70
Clean content: This would be unfortunate for Gentoo. We’re currently one of the few Linux distributions that aim to provide a reasonable working experience for people with older, weaker or more niche hardware that is not supported by Rust; and given that we’re largely talking about volunteers with no corporate backing, there is practically zero chance of ever porting LLVM and Rust to the relevant platforms, let alone providing long-term maintenance needed for keeping them working in projects with such a high rate of code churn. I do realize that these platforms are not “supported” by CPython right now. Nevertheless, even though there historically were efforts to block building on them, they currently work and require comparatively little maintenance effort to keep them working. Admittedly, the wider Python ecosystem with its Rust adoption puts quite a strain on us and the user experience worsens every few months, we still manage to provide a working setup. The moment CPython starts requiring Rust, this will no longer be possible. Of course, we will still be able to provide older versions of CPython for a few years, at least until some major package starts requiring the newer Python version. That said, I do realize that we’re basically obsolete and it’s just a matter of time until some projects pulls the switch and force us to tell our users “sorry, we are no longer able to provide a working system for you”. I don’t expect to change anything here. Just wanted to share the other perspective.
ID: 277603
Author: Stephan Sokolow
Created at: 2025-11-18T08:27:56.307Z
Number: 71
Clean content: I hope nobody will mind if my first post as a complete newcomer to the forum (though very far from one with Python or Rust) is letting my designed-to-win-trivia-games brain provide some context, clarifications, etc. for various things across the thread as a whole. Also, sorry for splitting this across multiple posts but, even after pessimizing all my citations to “Search for …” annotations, it was still claiming I had more than two links in it. (If this posts, then I guess it meant two reply-to-post embeds.) Pre-PEP: Rust for CPython Core Development I’m not a core dev nor expert in the internals of CPython, but I wanted to chime in to resonate with the question from @MegaIng , pointing out though that it looks to me (as a Python user) that the community in general is more “approachable” in comparison to what happened during the integration of some Rust in the Linux kernel. 
Out of curiosity, what would this mean for both PyO3 and RustPython ? Have you reached out to the mantainers of the latter for feedback on how to approach this possibilit… Finally, if I recall rust applications tend to be a bit “bloated” in binary size, although there are some tricks that can be done at compile time to reduce this - what do these tricks imply on performance I have no idea. The answer depends on how long ago you remember that from. Rust’s history has been a tale of improving defaults on this front and I don’t know where you draw the line on “bloated”. For example, prior to Rust 1.28 (Search for “Announcing Rust 1.28” site:blog.rust-lang.org ), some platforms embedded a copy of jemalloc but it now defaults to the system allocator. Rust still statically links its standard library, which is distributed as a precompiled “release + debug symbols” artifact to be shared between release and debug profiles and, for much of its life, there was no integrated support for stripping the resulting binaries. According to the Profiles (Search for “The Cargo Book” “Profiles” site:doc.rust-lang.org ) section of The Cargo Book, strip = "none" is still the default setting for the release profile. If I do a simple cargo new and then cargo build --release the resulting “Hello, World!”, the binary is 463K, which drops to 354K if the debuginfo is stripped. That remaining size includes things like a statically linked copy of libunwind which wouldn’t be needed if using abort on panic as mentioned by Emma Smith… but I’m not up to speed on how much of that will get stripped out without rebuilding the standard library to ensure it isn’t depending on them. (See my later mention of how the Rust team are currently prioritizing stabilizing -Zbuild-std as part of letting “remove kernelspace Rust’s dependency on nightly features” shape much of the 2025 roadmap.) Beyond that, one potentially relevant piece of tooling is dragonfire ( amyspark/dragonfire on the FreeDesktop Gitlab) as introduced in Linking and shrinking Rust static libraries: a tale of fire. (Search for “Linking and shrinking Rust static libraries: a tale of fire” site:centricular.com ) (Which is concerned with deduplicating the standard library when building Rust-based plugins as static libraries.) Pre-PEP: Rust for CPython Core Development Doesn’t “C“ in the name of “CPython“ means “C programming language”? If so, shouldn’t the project be eventually renamed when a significant part of it is (re)written in Rust? 
/joke, but who knows Just declare “CPython” to be referring to the stable ABI exposed rather than the implementation language. After all, the abi_stable crate for dynamically linking higher-level Rust constructs does it by marshalling through the C ABI.
ID: 277604
Author: Stephan Sokolow
Created at: 2025-11-18T08:28:34.839Z
Number: 72
Clean content: Pre-PEP: Rust for CPython Core Development I have long liked the idea of doing something like this, and as someone who always introduces memory leaks and segfaults and such any time he writes any kind of C extension code, I welcome the idea of more modern zero-cost abstractions for that [1] . 
However, one cost I think that has not been mentioned here is the effect that this could have on build times. In my experience, compile times for Rust (and C++) are much slower than for C. On my 2019 Thinkpad T480, from a fresh clone of CPython, I ca… I guess the question is a dual one: can we write Rust in a way that it will not cause build times to explode and if we cannot, is the plan to keep the scope of Rust in CPython to a level where building is still very accessible? I don’t see why it needs to be slow. As laid out in The Rust compiler isn’t slow; we are. (Search for "The Rust compiler isn't slow; we are." site:blog.kodewerx.org ), rustc is already faster than compiling C++ with GCC and the reason builds are slow has more to do with how much the Rust ecosystem enjoys the creature comforts of macros and monomorphized generics. Pre-PEP: Rust for CPython Core Development In my experience incremental Rust builds are also very fast–the initial setup (including downloading and building all the dependencies) can be slow, but it’s able to do fast incremental builds just fine. 
Also, there’s a big difference between debug and release mode–building in debug mode is way faster. I would be surprised if this impacted iteration time unless you’re trying to rebuild the world every time. …and they’re working on making it faster still. Aside from “Relink, Don’t Rebuild”, as mentioned by Jubilee, there are two bottlenecks which disproportionately affect incremental rebuilds right now: First, while there’s parallelism between crates and in the LLVM backend, the rustc frontend is single-threaded. Work is in progress and testable in nightly (Search for “Faster compilation with the parallel front-end in nightly” site:blog.rust-lang.org ) for making the frontend multithreaded. They’re also working on rustc_codegen_cranelift ( rust-lang/rustc_codegen_cranelift on GitHub) which is a non-LLVM backend for rustc which makes more Go-like trade-offs for compile-time vs. runtime performance and is intended to eventually become the default for the debug profile. Second, linking. They’ve been rolling out LLD as a faster default linker on a platform-by-platform basis and it came to Linux in 1.90. (Search for “Announcing Rust 1.90.0” site:blog.rust-lang.org ) Beyond that, mold is faster still (it’s what I use on my system) and wild ( davidlattimore/wild on GitHub), yet faster, is being developed with an eye toward becoming default for debug builds alongside rustc_codegen_cranelift. (i.e. Doesn’t cover all the needs of a fully general-purpose linker, but does make debug builds for the majority of them very quick.)
ID: 277605
Author: Stephan Sokolow
Created at: 2025-11-18T08:29:38.639Z
Number: 73
Clean content: I claim that one of the major reasons for this failure is that cargo is almost unique among build systems in providing absolutely no structured mechanisms for: (1) communicating with other package build scripts in the same dependency graph (2) communicating with the downstream user who invokes cargo (such as a distro packager, or a github actions pipeline) This is a known problem that’s been discussed more or less since v1.0 came out in 2015 but more pressing issues keep jumping ahead of it in the queue. (eg. The 2025H2 roadmap is prioritizing stabilizing an MVP of -Zbuild-std so that embedded and low-level projects like Rust for Linux (i.e. kernelspace Rust) don’t need to use either a nightly compiler or the secret switch to use API-unstable features on stable channel.) If you want to search up existing discussions, what was done to incorporate Rust builds into Bazel got mentioned a lot. Pre-PEP: Rust for CPython Core Development Nothing in particular. 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. It should be noted that, if I understand “GCC Testing Efforts” site:gnu.org correctly, GCC’s support for all platforms would count as “Tier 3, at varying degrees of stubbornness” by Rust testing standards since I don’t see any mention of any of the “Current efforts” entries being integrated to the same “CI on every push and will block merging into main if it fails” degree. Rust’s approach to Tiers 1 and 2 leans in the direction of “We don’t trust our testing to be sufficient for Continuous Deployment, but we’ll do it as diligently as if we were pushing directly to stable channel”. EDIT: …and, apparently, there’s also a limit on number of posts for new users so I can’t get it all in without breaking the rule about no substantial edits. I’ll drop an in-reply-to-embed and add a GitHub Gist containing the source for the entire thing as it was before I started making any changes to try to crunch it in. In total, the posts being replied to, as represented in the auto-updating Discourse permalink URLs, are 4, 9/12, 15, 16, 18, 19, 30, and 38, and a few I forgot to grab URLs for while blockquoting, and the bits which don’t fit include an answer to the concern about Trusting Trust attacks, a clarification about “Rust guarantees that code outside an unsafe {} block is safe”, a mention of #[repr(transparent)] , and a few other little things.
ID: 277606
Author: GalaxySnail
Created at: 2025-11-18T08:30:27.638Z
Number: 74
Clean content: If python cannot be built without rust in the future, I believe the difficulties this would bring to bootstrapping are being underestimated. Python is such a widely used programming language that many projects have started to use python during the build stage. For example, glibc and gcc require python to build ( https://github.com/fosslinux/live-bootstrap/commit/69fdc27d64ec56ad59b83b99aab0747c9d9f81ed ). If python depends on rust, it would mean that all projects using the meson build system would also need rust to bootstrap (I know muon can be a replacement, but muon isn’t 100% compatible with meson). The live-bootstrap project has already completed the bootstrap of python, and it currently requires a total of 11 builds to obtain CPython 3.11.1, including regenerating all generated code ( https://github.com/fosslinux/live-bootstrap/blob/master/parts.rst#159python-201 ). And even when using mrustc to build rust 1.74.0, it still requires 18 builds to obtain rust 1.91, especially since the time required to build rustc is much longer than CPython. Moreover, rust releases a new version every 6 weeks, so this number will grow quickly. Compilation time is also an issue. Although incremental builds in debug mode may be fast, this is not always possible, for example when doing distribution packaging, when using git bisect , or when debugging bugs that only reproduce in release mode. Currently, a full CPython build is still relatively fast, and I agree that it would be acceptable if the full build time were up to 2x slower. Regarding the previously mentioned issue with os.fork , I am not sure whether using fork in a single-threaded process is safe. If using fork in a single-threaded process would still break rust’s safety guarantees, then os.fork and multiprocessing.get_context("fork") would become completely unusable, and that would break many third-party libraries that depend on it. On the other hand, rust occasionally introduces breaking changes outside of editions, for example https://github.com/rust-lang/rust/issues/127343 , and the potential impact of such risks on CPython should be considered carefully.
ID: 277609
Author: David Hewitt
Created at: 2025-11-18T09:21:31.306Z
Number: 75
Clean content: Eclips4: Can we integrate MIRI into our workflow? I spoke to some of the Miri maintainers about running PyO3 through Miri a while ago, I believe back then there were limitations due to all the C FFI being opaque to Miri. I vaguely recall the conversation concluded those limitations could be lifted, would just need some work. I’m not aware of anything to make me think that work has been done yet. 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). At the moment PyO3 has two abstractions, the low level FFI which this pre-PEP proposes generating with bindgen and the high-level abstractions which are totally safe. I’ve wondered about a third level which sits between the two; it would still use unsafe extern “C” ABI and call the C symbols directly, but the types for input & output could encode the possible states, e.g. BorrowedPtr(*mut PyObject) or even Option<NonNull<PyObject>> to force null checking. As long as these are layout identical with the actual C type passed through the FFI, it would just improve type safety without actually introducing any overheads or much “high level” API. There is a lot of scope to experiment here. Gankra: In practical specific terms, it’s often reported that Rust often makes implicit ownership/lifetime constraints in C APIs explicit and easier to work with. The Rust bindings to C functions can include lifetimes that enforce these contracts (and yes a lot of C APIs map onto lifetimes and ownership well). I agree fully with this - in particular a huge win is that you don’t need to remember to call Py_Clear / Py_DecRef / Py_XDecRef on every error pathway, RAII abstractions can just solve this for you. Your point here also speaks to what I was musing about in the point above. barry: The former is surely a smaller number, and my guess is that even fewer are comfortable in Rust today . Absolutely true that while many core devs may not currently be comfortable in Rust, there is a lot of anectotal evidence that after an initial learning curve many people find Rust relatively easy to feel productive and comfortable in. (Google’s experience with Android strongly supports this, for example.) CEXT-Dan: Thank you, I know nothing of Rust, I see the word ‘dependency’ and I immediately get scared. Python and all the 3rd party modules must load into the host application’s process. In my case, I’m running Python inside AutoCAD for windows. If this is optional, or something that’s not going load some sort of runtime, or something that could cause issues, then great Many Python packages are already built in Rust, they’re precompiled and uploaded to PyPI as binary distributions which users can use without any awareness they’re built in Rust. CPython using Rust as an implementation detail would be no different for anyone not building from source. mgorny: Admittedly, the wider Python ecosystem with its Rust adoption puts quite a strain on us and the user experience worsens every few months, we still manage to provide a working setup. @mgorny the Python ecosystem user experience is important to me and I’m aware there have been pains as tooling has adopted to Rust support. Gentoo particularly runs into these pains due to so much from-source building and extensive hardware support. I’m sure I’m not aware of every possible configuration, please always do feel free to ping me / direct me at things and I will do my best to help. I build PyO3 / integrate Python & Rust to empower more people to write software, not to alienate.
ID: 277610
Author: Stephan Sokolow
Created at: 2025-11-18T09:33:34.110Z
Number: 76
Clean content: On the other hand, rust occasionally introduces breaking changes outside of editions, for example I don’t think it’s fair to call Rust out for that specifically, given that it’s not a Rust-specific problem and that, as demonstrated in places like graydon2’s retrobootstrapping rust for some reason , my prior mention of which got spilled into the GitHub Gist because “New users can’t…”, "Modern clang and gcc won’t compile the LLVM used back then (C++ has changed too much – and I tried several CXXFLAGS=-std=c++NN variants!) Modern gcc won’t even compile the gcc used back then (apparently C as well!) Modern ocaml won’t compile rustboot (ditto) While I don’t have numbers, given that Rust’s regression suite became a bottleneck on development before Microsoft started donating Azure time, and that they have Crater (a bot for testing proposed changes against slices of the public crate registry up to and including “all of it”), I suspect Rust introduces breaking changes less than C and C++ do.
ID: 277613
Author: Sergey "Shnatsel" Davidoff
Created at: 2025-11-18T10:26:36.392Z
Number: 77
Clean content: Rosuav: open questions such as the impact of a potential Ken Thompson style compiler hack . Will CPython lose trust by becoming dependent on a single specific compiler that might be subject to such a hack? There is an alternative Rust compiler implementation in C++, mrustc , that implements just enough Rust to compile the official Rust the compiler without relying on it in any capacity. The official Rust compiler bootstrapped both ways (original chain and mrustc) produce identical binaries, which is sufficient to prove the absence of the Ken Thompson hack.
ID: 277614
Author: Sam James
Created at: 2025-11-18T10:42:34.330Z
Number: 78
Clean content: It should be noted that, if I understand “GCC Testing Efforts” site:gnu.org correctly, GCC’s support for all platforms would count as “Tier 3, at varying degrees of stubbornness” by Rust testing standards since I don’t see any mention of any of the “Current efforts” entries being integrated to the same “CI on every push and will block merging into main if it fails” degree. Rust’s approach to Tiers 1 and 2 leans in the direction of “We don’t trust our testing to be sufficient for Continuous Deployment, but we’ll do it as diligently as if we were pushing directly to stable channel”. I don’t really want to derail this thread into a discussion on models of testing, but a similar discussion was had the other week on lobste.rs . I don’t think it’s a accurate summary to say Rust’s ‘testing standards’ just mean ‘Tier 3’ for GCC.
ID: 277616
Author: Stephan Sokolow
Created at: 2025-11-18T10:45:00.902Z
Number: 79
Clean content: Thank you. Is there any chance that clarification could be added to GCC Testing Efforts - GNU Project since that’s what shows up in search results?
ID: 277617
Author: Sam James
Created at: 2025-11-18T10:45:32.617Z
Number: 80
Clean content: In the thread, I did promise to work on improving documentation, so yes, it will be done. EDIT: Filed PR122742 for that.
ID: 277620
Author: Marc-André Lemburg
Created at: 2025-11-18T11:07:55.689Z
Number: 81
Clean content: I’m a firm -1 on proceeding in this direction. The reference implementation CPython is called CPython for a reason, after all, By adding additional requirements, we make CPython less portable, maintenance a lot harder and complicate adoption in spaces where you need to recompile the whole package to other platforms such as WASM. Besides, there already is a GitHub - RustPython/RustPython: A Python Interpreter written in Rust effort. I’m sure they’d love to get more support. If you want to use Rust for writing optional extensions, that’s perfectly fine, but please upload them to PyPI instead of requiring Rust in the CPython core.
ID: 277621
Author: Jacopo Abramo
Created at: 2025-11-18T11:19:03.755Z
Number: 82
Clean content: Members of both the RustPython community and PyO3 already expressed their interest in this approach, as already pointed out from the previous replies on this thread.
ID: 277622
Author: Antoine Pitrou
Created at: 2025-11-18T11:24:33.496Z
Number: 83
Clean content: David Hewitt: I spoke to some of the Miri maintainers about running PyO3 through Miri a while ago, I believe back then there were limitations due to all the C FFI being opaque to Miri. I vaguely recall the conversation concluded those limitations could be lifted, would just need some work. I’m not aware of anything to make me think that work has been done yet. And conversely, would a ASAN/UBSAN build of CPython be able to see/instrument the Rust parts? Otherwise, not seeing the full program execution could impair the ability of the instrumentation to find bugs at runtime.
ID: 277623
Author: Josh Cannon
Created at: 2025-11-18T11:49:37.806Z
Number: 84
Clean content: barry: One of the soft consequences I’m especially interested in is whether this attracts more or fewer core developers contributing to the Rust bits than the C bits. Anecdata: I don’t plan on writing any (more) C code, so outside of all the non-coding ways that exist, I don’t see myself ever meaningfully becoming a contributor to CPython (‘s core). On the other hand, I can’t write enough Rust to scratch the itch. And I don’t think I’m particularly unique or special here
ID: 277625
Author: David Hewitt
Created at: 2025-11-18T12:00:14.672Z
Number: 85
Clean content: pitrou: And conversely, would a ASAN/UBSAN build of CPython be able to see/instrument the Rust parts? ASAN can definitely work with the caveat that this is a nightly Rust feature at present - sanitizer - The Rust Unstable Book UBSAN - I’m less sure, I suspect that the C parts would be instrumented, the Rust parts would not, I would think this would not impact getting meaningful value from the sanitizer.
ID: 277628
Author: Kivooeo
Created at: 2025-11-18T12:30:12.238Z
Number: 86
Clean content: Hi from the Rust Compiler Team! As someone who programmed in Python for several years previously, I’m really excited to see this! I haven’t read the entire thread, but I have a minor concern that I previously raised personally with Kirill and wanted to bring here as well. After reading the PEP, one question remains regarding the specific version of Rust that will be used in Python. While Rust maintains excellent stability for the vast majority of users, large foundational projects like CPython often benefit from more conservative versioning strategies. Following approaches used by other large projects, would it make sense to pin specific Rust versions and update deliberately. Additionally, the policy around nightly features isn’t entirely clear. These often contain some quality-of-life improvements that might assist development. Within the Rust compiler itself, we regularly rely on many nightly features, so their treatment remains an open question from the PEP. These are the main points that I feel still need clarification after reading the proposal. Thank you for your tremendous work on integrating Rust into Python – it will be very exciting to watch this progress!
ID: 277633
Author: Michał Górny
Created at: 2025-11-18T12:55:29.578Z
Number: 87
Clean content: davidhewitt: mgorny: Admittedly, the wider Python ecosystem with its Rust adoption puts quite a strain on us and the user experience worsens every few months, we still manage to provide a working setup. @mgorny the Python ecosystem user experience is important to me and I’m aware there have been pains as tooling has adopted to Rust support. Gentoo particularly runs into these pains due to so much from-source building and extensive hardware support. I’m sure I’m not aware of every possible configuration, please always do feel free to ping me / direct me at things and I will do my best to help. I build PyO3 / integrate Python & Rust to empower more people to write software, not to alienate. Thank you, and I am grateful for your help whenever we run into specific problems with Rust. Unfortunately, here the problem is Rust itself — for platforms it doesn’t support, all we can do is either drop the package from that platform (which generally means also dropping all the packages that require it) or remove the Rust dependency somehow. For the latter, it often means disabling tests (which is far from optimal, but there’s at least some hope that testing on other platforms will suffice for pure Python packages), and lately replacing uv-build with a pure Python build system (say, when cachecontrol started using it, given it’s required by pip and poetry ).
ID: 277635
Author: Dima Tisnek
Created at: 2025-11-18T13:08:30.429Z
Number: 88
Clean content: Thank you Emma and Kirill for taking this on. The kudos you deserve is beyond what can be expressed in words. While I love reading the virtues of rust extolled… there are perhaps some areas that pre-pep should address that got glossed over. Rust’s approach to memory safety in multithreaded programs is very different from Python’s. In fact, I don’t think it can be used out of the box. Please make a plan or a PoC and show otherwise. Or set out an educated set of guards rails. Looking at the sample module, this stood out to me: #[inline]
fn encoded_output_len(input_len: usize) -> Option<usize> {
    input_len
        .checked_add(2)
        .map(|n| n / 3)
        .and_then(|blocks| blocks.checked_mul(4))
} This is just rust for the sake of rust. A safe C equivalent would be two lines long. The moral is that not all valid rust code belongs to CPython, just like PEP-7, there needs to be a spec about what rust features and idioms to use and what not to.
ID: 277637
Author: David Hewitt
Created at: 2025-11-18T13:24:41.824Z
Number: 89
Clean content: dimaqq: Rust’s approach to memory safety in multithreaded programs is very different from Python’s. From subinterpreters, yes I agree there are differences. From freethreaded Python, it has so far felt very similar to me (atomic datatypes, locks etc). dimaqq: This is just rust for the sake of rust. A safe C equivalent would be two lines long. This code could be written in a one liner if really wanted, I wouldn’t pick at LOC as a relevant metric. Some Rust code is more verbose than C because it encourages checking, some Rust code is less verbose because it (e.g.) handles RAII for you. #[inline]
fn encoded_output_len(input_len: usize) -> Option<usize> {
    (input_len.checked_add(2)? / 3).checked_mul(4)
}
ID: 277638
Author: David Hewitt
Created at: 2025-11-18T13:26:50.201Z
Number: 90
Clean content: dimaqq: The moral is that not all valid rust code belongs to CPython, just like PEP-7, there needs to be a spec about what rust features and idioms to use and what not to. clippy and rustfmt are fantastic tools (configurable) that enable a common standard of Rust to be used widely across the ecosystem with specific tailoring possible. I would think these will be great (possibly sufficient) starting points.
ID: 277643
Author: Alex Gaynor
Created at: 2025-11-18T13:56:47.268Z
Number: 91
Clean content: dimaqq: A safe C equivalent would be two lines long. FWIW, I’ve tried pretty hard, but I can’t find a way to write a (readable) 2-line version of this function in C that retains the overflow checking. (And any C version I do either relies on a magic sentinel like -1 for a return value or an out param, which is obviously more challenging for the caller). I think this is a good example of a dynamic with Rust: it definitely forces you to front load a lot of work. It’s more annoying for building POCs and playing with ideas. The trade-off is you get way less debugging and vulnerabilities on the back side.
ID: 277644
Author: Sergey Fedorov
Created at: 2025-11-18T14:00:13.923Z
Number: 92
Clean content: This is very disappointing to see rust being pushed into Python itself. That will break Python for all platforms where rust is broken, which will hit users badly, since a lot of apps rely on Python. (And will be a regression as compared to C implementation generally.) Using it optionally, like Ruby does, is fine. I honestly hope it does not become obligatory.
ID: 277645
Author: Jakub Beránek
Created at: 2025-11-18T14:07:34.735Z
Number: 93
Clean content: To provide some numbers on Rust’s build performance: today, I can build the whole Rust compiler (600 kLOC) plus its ~200 dependencies (a couple more hundred kLOC) on my Zen3 16 core (8C+8HT) laptop in ~50s from scratch, in release mode with optimizations, with incremental rebuilds taking 5-20s (depending on how deep I modify something in the dependency tree). While that is still slower than rebuilding CPython, especially in incremental, I don’t think that the initiative mentioned in this PEP would run into Rust build time performance issues soon, unless you somehow manage to write (or depend on) hundreds thousands of Rust code very quickly.
ID: 277648
Author: ShalokShalom
Created at: 2025-11-18T15:19:04.037Z
Number: 94
Clean content: Rust’s memory safety guarantees have been formally proven by the RustBelt project for code that does not use “unsafe” . There are CVE’s in safe Rust
ID: 277654
Author: Antoine Pitrou
Created at: 2025-11-18T15:42:51.203Z
Number: 95
Clean content: Well, there are CVEs in pure Python too, that doesn’t mean that Python and C are equivalent when it comes to avoiding security vulnerabilities.
ID: 277656
Author: Bill Janssen
Created at: 2025-11-18T16:41:48.408Z
Number: 96
Clean content: I think this is a great idea! So much so I finally signed onto the Discourse server to endorse it. Will follow developments with much interest.
ID: 277660
Author: Michael H
Created at: 2025-11-18T16:54:46.173Z
Number: 97
Clean content: No, but it does undercut the idea that the memory safety guarantees have been “formally proven” when there are longstanding known direct counterexamples. For what it’s worth, Miri does catch that issue.
ID: 277661
Author: Dustin Spicuzza
Created at: 2025-11-18T17:01:24.594Z
Number: 98
Clean content: Emma Smith: How should we manage dependencies? By default cargo will download dependencies which aren’t already cached locally when cargo build is invoked, but perhaps we should vendor these? Cargo has built-in support for vendoring code. We could also cargo fetch to download dependencies at any other part of the build process (such as when running configure). Currently, it is trivial to build python on a computer that isn’t connected to the internet. IMO this must continue to be the case, it’s really important to many users in restricted environments.
ID: 277663
Author: Michael H
Created at: 2025-11-18T17:20:53.414Z
Number: 99
Clean content: I have too many concerns about the use of Python in various bootstrapping to be in favor of this currently. I agree with the overall goal of increasing memory safety and making it easier to write code people can be confident in by default, and I like Rust for this, but I don’t see this as the right move without more supporting pieces that just aren’t there yet when considering how Python is used in the world. It seems more advantageous to focus on which modules have both C and Python implementations that would highly benefit from the guarantees afforded. This also seems to have cleaner boundaries on a technical level, and doesn’t force people to evaluate Rust adoption as an all-or-nothing roadmap to be committed to before it is proven to work within CPython’s core development, and before seeing actual impact of even that smaller transition. It’s also worth pointing out that there are options other than rust which have stronger formal guarantees than C (some more than Rust), and which don’t require a Rust toolchain. Python is already using GitHub - hacl-star/hacl-star: HACL*, a formally verified cryptographic library written in F* for various cryptography functions, and getting more from doing so than had a Rust implementation been chosen: The code for all of these algorithms is formally verified using the F* verification framework for memory safety, functional correctness, and secret independence (resistance to some types of timing side-channels). While Rust is certainly more popular than a purpose-chosen subset of F* [1] , it serves as a point that it is possible to get the level of additional compiler-enforced safety that’s desired without compromising on the existing portability of CPython. As CPython doesn’t support these unsupported triples either, Rust stabilizing user-provided JSON targets brings it to effective parity: “You’re on your own, but the build tools required have a stable way of doing it.” I also want to be crystal clear, I don’t think it’s even remotely feasible to say “Rust has to support all target triples that have ever used or ever will use python.” There’s a limited amount of maintainer bandwidth in every project, and some hardware just isn’t being developed for by the core teams. It’s niche. A probably less important issue, but one that I think hasn’t been mentioned directly [2] , is that rust and rust-analyzer both use significantly more memory than existing tooling for C. I don’t think it’s an amount likely to be a significant contribution barrier, and don’t personally count this against the proposal, but would like to make sure all known impacts are considered. Low* ↩︎ Compile times were mentioned, but there’s workflows that avoid the brunt of this. ↩︎
ID: 277666
Author: Norman Lorrain
Created at: 2025-11-18T17:37:57.979Z
Number: 100
Clean content: Given that Rust isn’t standardised like C and C++ (ISO/IEC 9899, ISO/IEC 14882), isn’t this premature?
ID: 277669
Author: Alex Gaynor
Created at: 2025-11-18T17:53:01.349Z
Number: 101
Clean content: Python is also not standardized, and yet I don’t think any of us believe it follows that it’s premature to use it . Can you expand a bit more on why you think standardization should play into this?
ID: 277671
Author: Kirill Podoprigora
Created at: 2025-11-18T17:56:54.370Z
Number: 102
Clean content: That’s a good question! But I guess the real question here is: what problem does standardization actually solve? Android and Linux seem to be doing just fine with Rust, even though it doesn’t have a formal standard. Here’s an article from Mara (a member of the Rust Leadership Council) that discusses this topic: https://blog.m-ou.se/rust-standard/ .
ID: 277672
Author: Stephan Sokolow
Created at: 2025-11-18T18:08:43.682Z
Number: 103
Clean content: The distinction is that those are implemented using I-unsound -tagged bugs in the compiler (and no comparably advanced optimizing compiler is completely free of them) and the underlying formal proof is for “if all compiler bugs are fixed”… similar to how you shouldn’t fault a language for the underlying DRAM being susceptible to Rowhammer . I don’t have the URLs on hand, but, if I remember correctly, GCC and LLVM have equivalent tags in their bug trackers. In this context, the reason some of those bugs are long-lived is twofold: The developers have determined that they’re very difficult to encounter accidentally. Neither the rustc devs nor the LLVM devs nor the GCC devs nor any developers of optimizing compilers are willing to take on “this transformation is a security boundary, fit for processing mailcious inputs”-level responsibility.
ID: 277673
Author: Stephan Sokolow
Created at: 2025-11-18T18:15:27.107Z
Number: 104
Clean content: Rust has multiple mechanisms for building without access to Crates.io , depending on the specific circumstances. For example: cargo fetch and cargo build --offline can be used to separate the downloading and building while otherwise using Cargo the same way. cargo vendor can be used to vendor the dependencies without losing the information that something like cargo-audit would need. The Overriding Dependencies section of the Cargo Book covers things like overriding the Crates.io repository URL to locally point a package at a different source. While I haven’t kept up on the state of the art, it’s possible to run a local mirror of Crates.io more broadly using tools like Panamax . I think that covers all the major tiers of the problem.
ID: 277674
Author: Norman Lorrain
Created at: 2025-11-18T18:16:54.221Z
Number: 105
Clean content: I think in terms of a tech stack, as you go further down you want to be increasingly conservative and prevent any breaking changes.  This has been the success of Windows, which for all it’s faults is quite backward compatible.  I can take code from 30 years ago and it will run.  Similarly for the Web.  I can look at archived pages from decades ago and it will display. Python is the foundation for many projects and businesses.  I trust that code I write today will run in 1 or 2 or 5 years.  10 years, less trust. Lessons learned from 2to3 transition. In turn, C is the foundation of Python.  I trust that any changes to C will not impact Python and my investment of time, etc. won’t be at risk. The core issue is trust. There is “currency” in trust.  Python has a healthy bank account of trust, and I fear it will be at risk.
ID: 277675
Author: Stephan Sokolow
Created at: 2025-11-18T18:22:07.057Z
Number: 106
Clean content: Generally speaking, standardization tends to come into play for one of two purposes: Re-unifying disparate implementations of a language (C, C++, ECMAScript, etc.) Making a proprietary product look more appealing to enterprise or government decision-makers (Java, .NET, Office Open XML, etc.) Given that Rust’s regression suite and v1.0 stability promise already pin the language down more thoroughly than C or C++ and that gccrs plans to follow rustc as the source of truth, I’m not sure a standard would have much benefit here. (Seriously. Look into how much about C is left implementation-defined. We generally greatly overestimate what the spec actually calls for. That’s one reason you tend to see big projects picking one or maybe two compilers per platform and coding against those. For example, the Linux kernel is written in GNU C and the ability to compile it using llvm-clang was a little bit about retiring use of features the kernel devs had decided were mistakes and overwhelmingly about teaching llvm-clang to support GNU C. …it also has its own non-standard memory model that only works because GCC is careful not to break it.)
ID: 277677
Author: Norman Lorrain
Created at: 2025-11-18T18:27:18.924Z
Number: 107
Clean content: See my other answer, regarding trust.  Having a standard provides some measure of trust in a technology that is a foundation of a project. I know nothing about Android, but I read that Ubuntu had a problematic release with their porting of uutils/coreutils to Rust in 25.10.  Those tools are a foundation to a Linux system. This undermines trust in Ubuntu. I’d hate for the same to happen to Python.
ID: 277678
Author: James Webber
Created at: 2025-11-18T18:28:16.038Z
Number: 108
Clean content: I don’t know that there is a level of standardization or certification that can satisfy every vague concern.
ID: 277679
Author: Stephan Sokolow
Created at: 2025-11-18T18:31:08.268Z
Number: 109
Clean content: Personally, my trust in Python was broken as soon as I saw lines in the standard library docs saying things like Deprecated since version 3.6, removed in version 3.12. (Specifically the latter half.) It’s one of the things that made me feel relieved that I’d decided to work on a Rust rewrite for any code that doesn’t need memory-safe QWidget bindings, Django’s ecosystem, or Django ORM/Alembic draft migration autogeneration in order to minimize the “It works. Don’t **** with it” vs. “Burned myself out again trying to reinvent a stronger type system in my test suite” factor.
ID: 277682
Author: Tin Tvrtković
Created at: 2025-11-18T18:38:17.862Z
Number: 110
Clean content: Love this effort, a strong +1 from me. I’ve been historically wary of bigger CPython contributions because I don’t know C, and don’t particularly want to know it. Rust is a completely different matter. A lot of the introduction here is aimed at Rust as a replacement for the C parts of CPython. But I think Rust could be a huge win for optimizing Python parts of CPython. “Rewrite module X in C” usually means a significant effort, both up front and on-going, maintenance-wise. Rewriting in Rust could be a completely different story, if we do this right.
ID: 277683
Author: Norman Lorrain
Created at: 2025-11-18T18:40:45.970Z
Number: 111
Clean content: Maybe a standardisation to the effect that code from The Rust book, 1st edition, or 2nd edition, still work with the latest Rust. (Perhaps it does).
ID: 277684
Author: Stephan Sokolow
Created at: 2025-11-18T18:44:18.998Z
Number: 112
Clean content: It should. See Stability as a Deliverable for a description of Rust’s “v1.0 Stability Promise”. Basically, so long as you’re not depending on a compiler bug or security hole, the only thing which should be allowed to break vN code in any later vN+M version of the Rust compiler is the occasional change to how type inference works in edge cases. …also, I almost forgot to mention this: Ubuntu’s troubles with uutils are, in my opinion and in the opinion of others, self-inflicted. The uutils devs are quite up-front that they haven’t yet achieved their goal of passing all the tests in the GNU Coreutils test suite, so Ubuntu trying to use them is similar to all the distros that made a mess by ignoring KDE’s announcement that 4.0 was meant to be a developer preview.
ID: 277685
Author: William Woodruff
Created at: 2025-11-18T18:47:05.212Z
Number: 113
Clean content: Norman Lorrain: The core issue is trust. There is “currency” in trust. Python has a healthy bank account of trust, and I fear it will be at risk. How should the Python community quantify this trust, given that your original metric (standardization) doesn’t apply to Python itself? Conversely: do you moderate your trust in CPython based on the presence of unstandardized, compiler-specific extensions? The last time I checked, there were a nontrivial number of GCC extensions and attributes in the codebase (other compilers go to great efforts to be compatible with these, but they’re not standard).
ID: 277686
Author: Sam James
Created at: 2025-11-18T18:47:33.294Z
Number: 114
Clean content: Basically, so long as you’re not depending on a compiler bug or security hole, the only thing which should be allowed to break vN code in any later vN+M version of the Rust compiler is the occasional change to how type inference works in edge cases. Use of unstable features in crates is more common than I’d like it to be still, and the promise does not apply to that. CPython should avoid any use of them. Rust for Linux currently relies on some such features, though they’re making an effort to stabilise the ones they’re relying on and not introduce more.
ID: 277687
Author: Sam James
Created at: 2025-11-18T18:49:54.681Z
Number: 115
Clean content: cargo fetch and cargo build --offline can be used to separate the downloading and building while otherwise using Cargo the same way. That option would require some work besides git clone which may not be desirable. It does bring up the general question of whether CPython would want to aggressively use crates (which can bring licence questions too) or not. CPython currently has a pretty small set of external dependencies.
ID: 277688
Author: Stephan Sokolow
Created at: 2025-11-18T18:55:21.893Z
Number: 116
Clean content: thesamesam: Use of unstable features in crates is more common than I’d like it to be still, and the promise does not apply to that. CPython should avoid any use of them. Fair point. I haven’t used nightly for anything but the occasional nightly-only tool run (eg. Miri) in at least five years, but then I don’t do kernelspace stuff and using Rust for microcontroller hobby programming is still on my TODO list. My experience has been that there isn’t much call for nightly for cargo build -ing userspace projects anymore. thesamesam: That option would require some work besides git clone which may not be desirable. It does bring up the general question of whether CPython would want to aggressively use crates (which can bring licence questions too) or not. CPython currently has a pretty small set of external dependencies. I’d imagine cargo vendor would probably be a better fit for that. Beyond that, cargo-deny is good for enforcing policy on dependencies (licenses, security advisories, etc.) and cargo-supply-chain helps to automate the process of inspecting who you’re trusting, independent of how many pieces they decided to split their project into.
ID: 277689
Author: Emma Smith
Created at: 2025-11-18T19:07:35.013Z
Number: 117
Clean content: I wanted to start by thanking everyone for their feedback on the proposal so far, and say that we look forward to continued discussion. After reviewing the discussion so far, we’ve decided to re-focus the (pre-)PEP to only propose the introduction of optional Rust extension modules to CPython. We hope that with experiences gained from introducing Rust for extension modules, Rust can eventually be used for working on the required modules and the interpreter core itself in the future. However, we will leave that to a future PEP when we know more and will not be proposing that as part of the current in-discussion PEP. This should address issues with bootstrapping, language portability, and churn. We’ve also been noting lots of other feedback we’ve received, but I wanted to call this one out in particular as it has been the source of a large portion of the discussion.
ID: 277691
Author: Chris Angelico
Created at: 2025-11-18T19:59:46.895Z
Number: 118
Clean content: William Woodruff: Conversely: do you moderate your trust in CPython based on the presence of unstandardized, compiler-specific extensions? The last time I checked, there were a nontrivial number of GCC extensions and attributes in the codebase (other compilers go to great efforts to be compatible with these, but they’re not standard). I would, but the moderation in question is relatively slight. There are two levels of trust: “Do I believe this isn’t malicious?” and “Do I believe that this is able to do what it promises?”. The compiler-specific extensions don’t significantly affect the first one (any sort of malicious implication has to be incredibly convoluted, like “the CPython devs are trying to force people to use GCC because they are trying to boost Richard Stallman’s fame and try to get him into the Guinness Book of Records” - or something equally ridiculous), though they do have an impact on the second (“in the event of a problem, do we have true options here?”). So, yes, it does impact trust, but not all THAT much. Non-standard/compiler-specific features, to me, recall the days of IE-specific features in web sites, which had the much-less-convoluted justification “Microsoft wants everyone to use IE so they have to buy Windows”. But the trust impact depends on how viable the threat is.
ID: 277692
Author: Elchanan Haas
Created at: 2025-11-18T20:20:28.247Z
Number: 119
Clean content: emmatyping: When should Rust be allowed in non-optional parts of CPython? I think the timeline you are laying out here is a bit too certain. I would instead propose a timeline based on the adaption of Rust within Python. In Python 3.15, ./configure will start emitting warnings if Rust is not available in the environment. Optional extension modules may start using Rust. (Same as PEP proposal) Once the Rust has enough usage within Python extensions a PEP will be created with a timeline of making Rust mandatory.
ID: 277694
Author: Emma Smith
Created at: 2025-11-18T20:32:56.369Z
Number: 120
Clean content: This is no longer the current plan, please see Pre-PEP: Rust for CPython - #117 by emmatyping I don’t think we should emit a warning now that these items will be entirely optional and we don’t have a plan for making Rust required. When that is proposed in a PEP, the timeline for emitting warnings and requiring Rust will be decided there.
ID: 277695
Author: Norman Lorrain
Created at: 2025-11-18T20:34:48.478Z
Number: 121
Clean content: I would quantify it in terms of the timeline a codebase will still run.  1,2,5,10 years. Yes, I moderate it.  I’ve been burned by changes, and I guess this is why a foundational change like moving to Rust causes concern.  Why not defer this to Python 4?
ID: 277696
Author: James Webber
Created at: 2025-11-18T20:44:25.949Z
Number: 122
Clean content: Because there’s no plan to ever have a Python 4.
ID: 277697
Author: William Woodruff
Created at: 2025-11-18T21:03:38.697Z
Number: 123
Clean content: Norman Lorrain: I would quantify it in terms of the timeline a codebase will still run. 1,2,5,10 years. Yes, I moderate it. I’ve been burned by changes, and I guess this is why a foundational change like moving to Rust causes concern. Why not defer this to Python 4? I don’t think CPython makes a hard and fast guarantee that your code will run unmodified in 1, 2, 5, or 10 years. But even if it did: the presence of Rust inside the runtime doesn’t seem material to that property, or at least is no more material to it than everything that happens on each minor release of Python 3 anyways.
ID: 277698
Author: James Webber
Created at: 2025-11-18T21:24:37.466Z
Number: 124
Clean content: Emma Smith: This is no longer the current plan, please see Pre-PEP: Rust for CPython - #117 by emmatyping Given that this thread reached 100+ posts in a day (!), you might want to edit the OP to make this clear. This thread is getting some broader coverage and I expect more people will be jumping in without reading the whole thing.
ID: 277713
Author: Zachary Harrold
Created at: 2025-11-18T23:28:51.925Z
Number: 125
Clean content: barry: I would go further and predict that this will never happen, and claim that it shouldn’t be a goal of the Rust-in-Python project. There are 10**oodles of person-years invested in the CPython core interpreter, and I just don’t see how that will ever be cost effective to rewrite, even as a Ship of Theseus . I mean, there’s already +12,777,745/-9,190,109 total changes in a project with (currently) 2,791,005 lines of text (git diffs include non-code so this count does too). Arguably, cpython has been rewritten at least 4 times now.
ID: 277714
Author: Emma Smith
Created at: 2025-11-18T23:29:22.571Z
Number: 126
Clean content: Good idea, I updated the OP to mention and link to the updates to the timeline section, but left the original text for posterity.
ID: 277721
Author: Filipe Laíns
Created at: 2025-11-19T02:32:15.541Z
Number: 127
Clean content: Hi, thank you for being willing to take on this project! The proposal overall seems great, with the proposal scope and bootstrapping story being the only potentially major issues I see. I am only gonna comment on that, as other folks are already addressing remaining concerns. This discussion is already big as-is, and I have no doubt it will still grow much larger Proposal scope Unless I am misinterpreting it, the proposal foreword seems to imply that this is a phased proposal that will eventually add Rust as a required build dependency of CPython, but the presented PEP only covers making it an optional build dependency. This proposal declares Rust will at some point will stop being optional. While I understand the motivation, I feel like deciding this right now is too early. I don’t think the PEP provides strong enough supporting evidence to outweigh the potential implications of such a major change. The downstream impact is still pretty up in the air, as is the impact on development, etc., while the potential benefit of introducing Rust into the core code-base is still very unclear. When I say the benefit of using Rust in core is unclear, I am not questioning Rust’s benefit over C. It’s the quantity of opportunities where it would make sense to use it that is unclear. I strongly believe we should not be rewriting existing code in Rust without a specific reason, and that’s what I think is unclear at this point. Even the PEP is unsure of the timeline for promoting Rust to a hard build dependency, probably because of this. I think this proposal would be much easier to drive forward if it were split into two phases, each with its own PEP. Introducing Rust as an optional build dependency Promoting Rust to a hard build dependency This way, 1) would allow us to gather feedback from the development team, downstreams, etc., giving us a much better picture of the impact of 2), enabling us to make a better argument and design a more concrete plan. With this in mind, here are my suggestions for the PEP text: Add an “Abstract“ section explaining that the PEP is a first step into the adoption of Rust in the CPython codebase, introducing it in an optional capacity, allowing us to experiment, gather developer feedback, and better assess the technical implications of using Rust in CPython. Add a “Goals“ section Explicitly state that rewriting existing code in Rust without further motivation is a non-goal Define a couple of goals, like the following Evaluate how well the development team engages with Rust inside the codebase Evaluate how well the CPython architecture couples with Rust Evaluate the impact of first-party Rust APIs on downstream users (eg. PyO3) Gather feedback from downstream users regarding the bootstrapping implications Gather feedback from downstream users of platforms where Rust is not supported Add a “Future“ section explaining that, contingent on the impact of this PEP, we plan to promote Rust to a hard build dependency as a next step Remove “Keep Rust Always-Optional“ from “Rejected Ideas” TLDR I don’t feel the PEP provides enough justification to make Rust a hard build dependency, and I think that’s something that would be difficult to provide at this point. As such, I feel like this proposal would be better served by splitting into two phases/PEP — starting with adding Rust as an optional build dependency, and then promoting it into a hard build dependency. Bootstrapping I personally don’t think any of the given solutions are good enough at the moment, so it is very important to explore other options. IMO, even if no better solutions are found, the PEP authors should show they have exhausted all other sensible possibilities. That said, I may be mistaken, but it’s my understanding that Python should only be needed to build LLVM for rustc . Perhaps it would be worth exploring the possibility of using the Cranelift backend instead, which AFAICT doesn’t need Python. It may also be worthwhile to engage with the mrustc project, as they may have better insights on other possible approaches. Another thing that I thought it would be pertinent to point out. If we were to introduce Python to the bootstrapping dependency tree (via Rust), that would greatly weaken the argument against moving CPython’s build system to Meson (discussion in What do you want to see in tomorrow’s CPython build system? ).
ID: 277722
Author: James Webber
Created at: 2025-11-19T02:34:58.859Z
Number: 128
Clean content: Filipe Laíns: I don’t feel the PEP provides enough justification to make Rust a hard build dependency, and I think that’s something that would be difficult to provide at this point. Good news, this was agreed upon somewhere in the next 100ish posts of the thread.
ID: 277725
Author: Stephan Sokolow
Created at: 2025-11-19T04:03:18.487Z
Number: 129
Clean content: I claim that one of the major reasons for this failure is that cargo is almost unique among build systems in providing absolutely no structured mechanisms for: (1) communicating with other package build scripts in the same dependency graph (2) communicating with the downstream user who invokes cargo (such as a distro packager, or a github actions pipeline) An update on work in this direction: The GSoC results page details progress on Prototype Cargo Plumbing Commands . Not what you asked for, but evidence of how this sort of thing is on the radar.
ID: 277731
Author: Alyssa Coghlan
Created at: 2025-11-19T06:59:55.463Z
Number: 130
Clean content: I’ll chime in with a +1 on the idea of allowing Rust extension modules, -1 (at least for now) for the core interpreter and compiler (which is already the direction the descoped PEP has moved in). For the core interpreter (at least the part which needs to be built in order for CPython to freeze its own frozen standard library modules), I think the bootstrapping and long tail platform support concerns are significant enough to at least postpone consideration of the possibility, and potentially even enough to block it forever. For extension modules manipulating untrusted input data, I see huge potential value in having access to Rust as a fast low overhead statically typed language with rich data structures and implicitly thread local data access. (For a concrete example of that from nearly 10 years ago, here’s a Sentry post about migrating their JavaScript source map processing from Python to Rust , and the benefits of not incurring the per-instance overhead of creating full Python objects). There are some cases where platform compatibility may still be a concern, but extension modules will have more options for handling that than the core interpreter does.
ID: 277732
Author: Dima Tisnek
Created at: 2025-11-19T07:09:23.108Z
Number: 131
Clean content: alex_Gaynor: dimaqq: A safe C equivalent would be two lines long. FWIW, I’ve tried pretty hard, but I can’t find a way to write a (readable) 2-line version of this function in C that retains the overflow checking. My take: if (len > PRECOMPUTED_CONST) return -1;
return (len + 2) / 3 * 4; My point was exactly about the fact that crustaceans worry about overflow checking, borrow safety, traits, etc., and write verbose code that is beautiful, while pragmatic folk reduce the problem, put safety limits leaving the implementation very short. After all, what’s the point of encoding a string that’s larger than a fraction of the total address space? The Rust overflow checker is only effective at ~3/4 RAM, at which point the argument and result cannot fit into RAM at the same time. Fancy Rust safety is totally appropriate for user-defined or external input (e.g. networking code, cryptography or json.dumps argument where some inner dict-like object may have a custom dunder method that does some “caching” but ends up modifying sibling elements in flight or creates cycles), while simple concepts should in my opinion remain simple, so that the code remains maintainable, ideally also by contributors who are not Rust experts. Which is why I’m calling for the equivalent of PEP-7 for Rust use in CPython. ShalokShalom: Rust’s memory safety guarantees have been formally proven by the RustBelt project for code that does not use “unsafe” . There are CVE’s in safe Rust I’d go even further and decry “proven safe” as smoke and mirrors. Remember the BAN logic proof for the Needham–Schroeder protocol? To recap, every proof is against a certain fixed set of assumptions. Meanwhile what happens in practice is that software is reused in ways unpredictable a priori. RustBelt has proven something about Rust, but not about Rust use in CPython, or Rust use in 3rd party Python extensions and certainly not about Rust used within CPython when an arbitrary user program is run by the interpreter, with arbitrary additional extension, for arbitrary goals and with arbitrary thread model. Here my call is to move most of Rust exultations into the footnotes, and focus on tangible direct benefits instead: safer refactoring / faster reviews, broader contributor pool / potentially more approachable to new contributors who grew up with safe/typed languages, specific CPython core bug classes (not generic C bugs), cleaner (more self-documented) internal APIs, safer norms for 3rd party extensions, possibly safer/faster backport story, potentially better tooling, possibly CPython guts (e.g. regexp) shared as crates for other uses…
ID: 277734
Author: Emma Smith
Created at: 2025-11-19T07:32:31.612Z
Number: 132
Clean content: Dima Tisnek: Which is why I’m calling for the equivalent of PEP-7 for Rust use in CPython. This is definitely something I hope to work on with folks. We will need a standard style for Rust in CPython, but I also think that might depend as we adopt Rust and expand the current proof of concept. Regardless it probably should be it’s own PEP, in my mind drafted and published after this one is approved. Dima Tisnek: RustBelt has proven something about Rust, but not about Rust use in CPython That’s certainly true, but in projects that have adopted Rust for a while, we see significant decreases in memory safety bugs. Here’s an excerpt from a blog about Rust adoption in Android: We adopted Rust for its security and are seeing a 1000x reduction in memory safety vulnerability density compared to Android’s C and C++ code . But the biggest surprise was Rust’s impact on software delivery. With Rust changes having a 4x lower rollback rate and spending 25% less time in code review Our historical data for C and C++ shows a density of closer to 1,000 memory safety vulnerabilities per MLOC. Our Rust code is currently tracking at a density orders of magnitude lower: a more than 1000x reduction. From Google Online Security Blog: Rust in Android: move fast and fix things I agree with you that it is important to highlight that Rust can increase developer velocity as well as provide memory safety. I think this is something we will highlight more in the PEP draft and is something a few people have mentioned. Here’s another excerpt from the above blog related to that: For medium and large changes, the rollback rate of Rust changes in Android is ~4x lower than C++. Rust changes currently spend about 25% less time in code review compared to C++. These are definitely things we will be focusing on more in the PEP text itself.
ID: 277740
Author: Stephan Sokolow
Created at: 2025-11-19T08:50:24.905Z
Number: 133
Clean content: dimaqq: To recap, every proof is against a certain fixed set of assumptions. Meanwhile what happens in practice is that software is reused in ways unpredictable a priori. RustBelt has proven something about Rust, but not about Rust use in CPython, or Rust use in 3rd party Python extensions and certainly not about Rust used within CPython when an arbitrary user program is run by the interpreter, with arbitrary additional extension, for arbitrary goals and with arbitrary thread model. While I agree that focus should be on other benefits (eg. I spent a decade in /r/rust/ and people coming from C++ loved the tooling most), I think it goes too far to call “proven safe” smoke and mirrors. That stance generalizes far too easily to things like “It’s a waste of time to make Python memory safe because import ctypes exists”, which makes it far too easy for people to dismiss… especially when the whole point of things like the safe/unsafe split and the way parts of Rust have been formally verified is to draw boxes around bits of code and say “assuming no external factor, such as bad RAM or abuse of unsafe violates the invariants, this code’s behaviour will meet expectations”.
ID: 277741
Author: Ricardo Robles
Created at: 2025-11-19T08:53:05.681Z
Number: 134
Clean content: I’m not a Rust expert; I only have work experience with C/C++ and Python. What advantages would Rust have over other languages ​​like Go? I’m just asking to understand Rust’s advantages and to make sure it’s for a real reason and not just to “Rustify” everything.
ID: 277742
Author: Stephan Sokolow
Created at: 2025-11-19T08:55:50.106Z
Number: 135
Clean content: Go depends on having a garbage collector and garbage collectors are solitary creatures, which makes it unsuitable for writing extensions or rewriting components of a C or C++ codebase. (That’s one reason Jython and IronPython exist, instead of integrating CPython with the JVM and CLR. They live within the JVM or CLR’s existing GC instead of competing with it.) Rust is noteworthy because it’s the only language to gain significant traction in this niche previously held almost exclusively by C and C++. EDIT: To elaborate on that, Rust enables compile-time guarantees that C and C++ are incapable of without relying on a heavy VM to do it. That’s what makes it essentially unique. (Though other languages like D and Ada are starting to copy Rust’s innovations.)
ID: 277746
Author: Miraculixx
Created at: 2025-11-19T09:06:42.019Z
Number: 136
Clean content: Not a core dev, yet experienced in large scale sw development including changing of core tech. Spoiler alert: these efforts usually fail. I always recommend to answer three key questions before embarking on changing foundational pieces of the stack: Is the new stack introduced for its coolness instead of solving an actual problem? Will the new stack introduce new problems that the old stack does not have? Does the investment in time and effort to introduce the new stack compete with more worthwile work that delivers value to users? If the answer to any of these questions is yes, and the change is pressed on anyway, the outcome will eventually land in one of two states: Efforts will stall and the resulting two-stack system is more complex than ever before, effectively meaning the change will be consuming ever more resources to no good cause. The complexities introduced by the new stack have a far higher blast radius than previously anticipated, triggering a complete rewrite, eventually reaching feature parity with no added value. In short, I recommend to avoid the introduction of Rust as an alternative to C in CPython(!).
ID: 277749
Author: Kirill Podoprigora
Created at: 2025-11-19T09:34:33.025Z
Number: 137
Clean content: Miraculixx: Not a core dev, yet experienced in large scale sw development including changing of core tech. Spoiler alert: these efforts usually fail. We’ve received a lot of messages from people who want to help, and even members of the Rust core team are willing to support us. As we mentioned earlier, there are two strong examples of Rust adoption done right: Rust for Linux and Rust for Android. Here’s the blog post from the Android team: Google Online Security Blog: Rust in Android: move fast and fix things We’re fully committed to putting a lot of effort into this initiative, and to making sure we don’t fail Miraculixx: Is the new stack introduced for its coolness instead of solving an actual problem? We’re addressing a real problem: CPython like many other projects written in C or C++ suffers from memory-safety vulnerabilities. Rust can drastically reduce the number of these vulnerabilities. From the Android blog post: We adopted Rust for its security and are seeing a 1000x reduction in memory safety vulnerability density compared to Android’s C and C++ code . Miraculixx: Will the new stack introduce new problems that the old stack does not have? I’m pretty sure this project will encounter at least one challenge: CPython contributors who don’t know Rust will need to dedicate some time if they want to contribute to the Rust parts. Other challenges will only become clear as we move forward, and that’s where members of the Rust core team may be able to help us. As I understand it, they supported the Rust for Linux project as well. Miraculixx: Does the investment in time and effort to introduce the new stack compete with more worthwile work that delivers value to users? Sorry, but I’m reading that part of your message as if this were about business. CPython is an open-source project, and most of us volunteer our time for free. Because we’re volunteers, we’re free to choose whichever problems we want to work on. So, we chose this problem and here’s the solution we believe in: Rust . Miraculixx: Efforts will stall and the resulting two-stack system is more complex than ever before, effectively meaning the change will be consuming ever more resources to no good cause. The complexities introduced by the new stack have a far higher blast radius than previously anticipated, triggering a complete rewrite, eventually reaching feature parity with no added value. I’d like to quote Android blog again: But the biggest surprise was Rust’s impact on software delivery. With Rust changes having a 4x lower rollback rate and spending 25% less time in code review , the safer path is now also the faster one.
ID: 277752
Author: Miraculixx
Created at: 2025-11-19T09:52:56.490Z
Number: 138
Clean content: Eclips4: We’re fully committed to putting a lot of effort into this initiative, and to making sure we don’t fail Said every team ever. I don’t doubt that. Just for reference, can you point to some of the memory saftey issues that would have been avoided if CPython were using Rust?
ID: 277758
Author: Zander
Created at: 2025-11-19T10:08:08.246Z
Number: 139
Clean content: It is undeniable that Rust offers superior safety over C and can effectively prevent many errors that would otherwise occur. However, introducing Rust into CPython may inevitably lead to some divergence within the community, with some developers in favor and others potentially having reservations. Additionally, this would require developers to be proficient in C, Rust to effectively address related issues. More importantly, as the proportion of Rust code in the project gradually increases, there may be growing calls within the community for a full transition of CPython to Rust. This could further intensify disagreements among core developers, somewhat reminiscent of certain situations the Linux community has experienced in the past. If all proceeds smoothly, we might eventually achieve a RustPython that remains compatible with the C ABI. That said, RustPython already exists today, though it still lags behind CPython in terms of features and ecosystem. Wouldn’t steadily improving it be a more feasible path forward? This approach may prove more manageable than integrating Rust directly into CPython. If there is a clear advantage to introducing Rust into CPython, it may lie in the ability to gradually migrate the official Python implementation from C to Rust while preserving existing functionality and compatibility. If the current path is maintained, CPython will continue to be implemented in C, and even if RustPython develops remarkably, replacing the official implementation would present significant challenges—since doing so would likely require the current maintenance team to undergo a major transition.
ID: 277762
Author: Kirill Podoprigora
Created at: 2025-11-19T10:12:51.385Z
Number: 140
Clean content: gh-133767: Fix use-after-free in the unicode-escape decoder with an error handler by serhiy-storchaka · Pull Request #129648 · python/cpython · GitHub and many other UAFs
ID: 277764
Author: Stephan Sokolow
Created at: 2025-11-19T10:53:11.705Z
Number: 141
Clean content: Zander-1024: If all proceeds smoothly, we might eventually achieve a RustPython that remains compatible with the C ABI. That said, RustPython already exists today, though it still lags behind CPython in terms of features and ecosystem. Wouldn’t steadily improving it be a more feasible path forward? This approach may prove more manageable than integrating Rust directly into CPython. Whenever I see arguments like this, I get the impression that the people making such an argument forget what “volunteer” means. If they’re not getting paid to work on Python, then it’s entirely possible that it’s not “Rust vs. C”, but “Rust vs. wear out and stop contributing”. I know that situation is why I’m rewriting my Python projects in Rust. Even without memory safety on the line and even with strict-mode MyPy, the constant vigilance of a dynamic language with ubiquitous NULL/None/nil and exceptions introducing hidden return paths all over the place wears on me.
ID: 277785
Author: Jacopo Abramo
Created at: 2025-11-19T15:17:01.954Z
Number: 142
Clean content: I don’t want to bring fuel to the fire as I’m just observing the decision making process, but the timing of the situation was just too funny for me. Apparently in September Cloudflare migrated some internal library to Rust … … and after investigation, the recent November outage was effectively caused by some code that wasn’t appropriately managing memory in this new library. But at any rate the pre-PEP has already been discussed exhaustively, it was just my sense of humour that found this hilarious in the context of this discussion where lots of points about integrating Rust were about memory safety.
ID: 277790
Author: Paul Moore
Created at: 2025-11-19T15:43:03.986Z
Number: 143
Clean content: Stephan Sokolow: If they’re not getting paid to work on Python, then it’s entirely possible that it’s not “Rust vs. C”, but “Rust vs. wear out and stop contributing”. This is a good point that doesn’t seem to be getting enough attention. I can’t speak for any of the core devs that routinely work on the C parts of the codebase, but I can say that personally, there were a number of improvements that I would have loved to make to the old py launcher, which I gave up on because I couldn’t face the manual memory management, and pointer manipulation, involved in string processing in C. If the launcher had been written in Rust [1] , then I could have used Rust’s standard string type, and as a result I would have been motivated to work on those improvements. So yes, a significant benefit of using Rust, even just for isolated parts of the Python stdlib, is that it could dramatically reduce the risk of developer burnout. Of course, we have to take care not to have the transition process burn people out as well, but I’m in favour of doing extra work to manage a short-term transition exercise in order to set up a better long term foundation. An entirely reasonable possibility, it was self contained, and its build process is isolated from the core build. ↩︎
ID: 277807
Author: Roman Vlasenko
Created at: 2025-11-19T17:20:57.412Z
Number: 144
Clean content: jacopoabramo: it was just my sense of humour that found this hilarious in the context of this discussion where lots of points about integrating Rust were about memory safety. I’d say that this is misleading. The Cloudflare’s outage actually has nothing to do with the memory safety guarantees of Rust or with inappropriately managing memory in general.
ID: 277808
Author: Davide Rizzo
Created at: 2025-11-19T17:27:57.550Z
Number: 145
Clean content: I’m a huge fan of this proposal. Thanks everyone for the effort. I volunteer to support in the endeavor in any way needed. The technical details can be discussed in due time, but one thing I’d love is for CPython API to define things around ownership and thread safety more formally. Right now this is delegated to documentation, but both C users and foreign language binding implementers (e.g. Rust and C++) would benefit if they could verify that a certain reference is meant to be owned or borrowed and so on. I understand there are challenges on both the technical and social aspect. I wish for both the aspects to be cared for seriously (and I renew my availability for help). It’s not the first time that adoption of Rust in a big project brings up some strong [1] resistance. I feel that there is space to adequately understand needs and worries; and to empower the people who have some stake in this change to impact the process. For example, some people brought up a worry that Rust is chosen because it’s a trendy toy rather than an actual solution. It’s good to spend time identifying why this is considered a problem, why it is a worry, and what can be done to address it. In part this is being done now (thanks to everyone who took time to answer) by reassuring that there is technical merit and proper research into the solution. But maybe this is not the whole argument and people would like to hear something closer to their worry. In other contexts I’ve seen a resistance to Rust adoption as a sort of threat to job stability (growing as a proficient C programmer takes a huge investment and attention to a number of issues, and something like Rust seems to promise to automate away part of your skill set), and maybe that also needs to be treated with care and empathy. And, on the other side, people wanting to see Rust introduced have their needs (that might not be entirely obvious besides the technical value) and might be faced with walls and gatekeeping and, as it happened in other projects, could be discouraged or burn out when they don’t see those needs understood, or their good will acknowledged. So, please, let’s not disregard that this is a socially loaded topic, and people are already reacting in many ways. I hope that the discussion will be smooth but I will not bet on it. and, sometimes, unexpectedly violent or vicious. Fortunately nothing of that sort is visible on this thread. ↩︎
ID: 277812
Author: Stephan Sokolow
Created at: 2025-11-19T18:58:54.670Z
Number: 146
Clean content: To elaborate on “nothing to do with […] Rust”, the outage was down to: We wrote a recipient service which preallocates memory as an optimization. Since we wrote it to ingest data from one of our other services, we made the assumption the data would always be well formed and had it preallocate 3⅓ times as much space as we’re currently using. We committed a bug to the sender service which caused it to produce data bundles that blew past that 3⅓ times safety margin. It’s a logic bug. If they’d written it in C or C++ it would have been an ASSERT or SIGSEGV and, in Rust, it was doing the equivalent of dying with an uncaught AssertionError . (Basically, a violation of “Assume ‘unreachable’ never is”.)
ID: 277835
Author: Emma Smith
Created at: 2025-11-19T22:33:31.068Z
Number: 147
Clean content: Davide Rizzo: I volunteer to support in the endeavor in any way needed. Excellent! Thank you! Davide Rizzo: The technical details can be discussed in due time, but one thing I’d love is for CPython API to define things around ownership and thread safety more formally. Right now this is delegated to documentation, but both C users and foreign language binding implementers (e.g. Rust and C++) would benefit if they could verify that a certain reference is meant to be owned or borrowed and so on. I think that in Linux they have seen a number of improvements by better defining the ownership of various parts of the kernel, so this would be very nice. I think it may be a while before it is feasible, but we shall see! Davide Rizzo: So, please, let’s not disregard that this is a socially loaded topic, and people are already reacting in many ways. I hope that the discussion will be smooth but I will not bet on it. Very important to remember! Going into working on this proposal I was trying to be very cognizant that this topic can engender strong feelings. I think overall I have been pleased with how the discussions have gone so far. I think so far folks have demonstrated that they can engage on this topic in a level-headed and cordial manner. I hope that trend continues. I also hope it has been clear in my own communications that I hope to understand and care about the the views of people who may disagree with the proposal. I do not want to drive away current contributors. I will also re-iterate that if anyone would like to chat about concerns regarding the proposal not in a discussion thread, please feel free to DM me!
ID: 277845
Author: Emma Smith
Created at: 2025-11-19T23:53:39.410Z
Number: 148
Clean content: Zander: RustPython already exists today, though it still lags behind CPython in terms of features and ecosystem. Wouldn’t steadily improving it be a more feasible path forward? I don’t think so for a couple of reasons. First, RustPython are semantically different enough that I think merging the semantics would be a significant undertaking: Jeong, YunWon: RustPython isn’t something that can be considered in this PEP in short term. RustPython and CPython are not semantically compatible across many layers of their implementation. Jeong, YunWon: RustPython has its own approach to running without a GIL, but it’s not compatible with CPython’s nogil direction. Second, introducing Rust to CPython would see direct benefits to the millions of users CPython has today. Improving RustPython might see benefits to it’s current user base, but to get current CPython users to switch would need to be earned through proven compatibility over a long time period. That sounds like much more of an uphill battle with unclear benefits.
ID: 277847
Author: Brett Cannon
Created at: 2025-11-20T00:22:54.256Z
Number: 149
Clean content: Alyssa Coghlan: long tail platform support concerns FYI Git 2.52 now optionally uses Rust and it will be required in Git 3 . Zander: introducing Rust into CPython may inevitably lead to some divergence within the community Divergence how? The key people who would be affected by this are: Core developers People who build CPython from source But as has already been stated, the PEP will have Rust usage be optional, so really, the people who will be affected by the planned PEP are: Core developers And so far I have seen more +1 than -1 from core developers. Paul Moore: If the launcher had been written in Rust GitHub - brettcannon/python-launcher: Python launcher for Unix (although admittedly I’m now curious to see if Python performance is such that I can just do it in pure Python and package it up appropriately).
ID: 277849
Author: H. Vetinari
Created at: 2025-11-20T00:58:32.354Z
Number: 150
Clean content: Emma Smith: I think that in Linux they have seen a number of improvements by better defining the ownership of various parts of the kernel, so this would be very nice. This is one of the points that Greg KH [1] explicitly calls out repeatedly as a benefit of the Rust-for-Linux effort, even if Rust went away again (here’s a recent talk with a timestamped link ): By forcing the C APIs to define their semantics, the C APIs themselves often were improved. one of the most veteran Linux contributors, maintainer of LTS kernels and involved in every security issue ↩︎
ID: 277874
Author: GalaxySnail
Created at: 2025-11-20T04:51:04.783Z
Number: 151
Clean content: Brett Cannon: FYI Git 2.52 now optionally uses Rust and it will be required in Git 3 . Git 2 → Git 3 sounds like Python 3 → Python 4. Git isn’t a programming language, you only need an implementation of Git’s wire protocol to interoperate with others, don’t even need to keep the on-disk format compatible. I don’t think Git’s choice necessarily tells us what we should do for CPython. Since the authors of this pre-PEP have already decided to make Rust optional for CPython, there isn’t much more to discuss about making Rust required.
ID: 277875
Author: Stephan Sokolow
Created at: 2025-11-20T05:10:25.037Z
Number: 152
Clean content: Git 3 is bringing in support for SHA256 commit hashes, which is a protocol break. (From what I remember, Rust is used to write the part which allows seamless SHA1 → SHA256 transitioning within a repo.)
ID: 277888
Author: Da Woods
Created at: 2025-11-20T07:02:05.591Z
Number: 153
Clean content: Question related to RustPython: they look to have made good progress on compatibility but not great progress on performance so far. Is there anything to be learned from why? I.e. if it’s just lack of time and contributors then it probably isn’t very interesting to this discussion, but if they were finding some optimisations difficult in Rust it might be useful to know.
ID: 277894
Author: Jeong, YunWon
Created at: 2025-11-20T08:17:12.463Z
Number: 154
Clean content: da-woods: Question related to RustPython: they look to have made good progress on compatibility but not great progress on performance so far. Is there anything to be learned from why? 2 main reasons, which are mirror-side of each other. First, the core language part of CPython is very well optimized. RustPython adopt a few parts of them, but not able to finish major parts of them. Second, RustPython contributors (like me) didn’t have enough interests on the performance. So it happened just occasionally. So… that’s not by technical issues. Just lack of driving to the performance. If anyone interested in enhancing performance of RustPython, I will do my best support.
ID: 277898
Author: Jeong, YunWon
Created at: 2025-11-20T08:27:30.787Z
Number: 155
Clean content: emmatyping: Interactions between Python objects and borrows is rather complicated. I don’t think this thread is a great place to go over detailed API design discussion as that isn’t the goal of the PEP, but I’d be happy to chat in another forum like the Python Discord or via DM. I will say a pie-in-the-sky API will look somewhat like an implementation using PyO3 . A sample clone in RustPython; it is not PyO3 though. The technical details will differ, but once Rust for CPython gains sufficient abstraction, it will reach a similar level in terms of cognitive load. github.com/youknowone/RustPython _base64 main ← _base64 opened 08:08AM - 20 Nov 25 UTC youknowone +87 -0 ## Summary by CodeRabbit

* **New Features**
  * Base64 encoding support is now … available in the standard library. Users can encode binary data into standard Base64 format with built-in error handling and safety guarantees for large datasets. This enables reliable and efficient data transformation for applications requiring text-safe data representation and enhanced cross-platform system compatibility.

<sub>✏️ Tip: You can customize this high-level summary in your review settings.</sub>
ID: 277904
Author: Mark Shannon
Created at: 2025-11-20T09:58:39.817Z
Number: 156
Clean content: Personally, I think this makes a lot of sense for extension modules and some components, but not so much for the core of the VM (the interpreter, gc, and core objects). The safety, or lack of safety, of those components depends not so much on the language they are written in, but the design. If you feed dodgy bytecode to the interpreter it should crash, or worse. That’s how it is supposed to work. What is the proposed API for rust? The section on implementation talks about using bindgen, but what is the underlying C API that you are binding? The limited API or the warts-and-all “unlimited” API? You mention PY_OBJECT_HEAD_INIT but that just couples rust code to the deep internals of the VM. If we are introducing a new API, then it should be a good one. It should follow the design on HPy , or its successor PyNI . The linear typing of HPy handles should work very well with rust’s ownership model.
ID: 277922
Author: Steve Dower
Created at: 2025-11-20T14:53:31.669Z
Number: 157
Clean content: H. Vetinari: By forcing the C APIs to define their semantics, the C APIs themselves often were improved. Yes, I think this is the best we can look forward to if the plan to progressively replace the core runtime implementation with Rust were still on the cards (which I assume it is, just unofficially for now - it doesn’t make any sense at all to “put Rust in CPython” without that ambition, since you can already write an extension module using Rust without our permission [1] ). And we are already working to improve the semantics of our C APIs as quickly as we can without destroying our existing user base - adding Rust won’t help here (it’ll let us get away with more breakage for some people “because Rust”, but it’ll upset other people who still want minimal breakage, and on average I expect it’ll make no real difference). What the current proposal comes down to is “can we make some stdlib extension modules optional for some people”, where the answer is obviously “yes” as we already make a number of them optional for users who don’t have/support/want certain third-party libraries. So the slightly higher-level question is “are we willing to make some modules optional based on compiler choice, rather than based on access to the core functionality required by the module”. (For example, if I don’t want/have OpenSSL, then the _ssl module is obviously useless and best omitted. But if I don’t want/have Rust, why should I miss out on _base64 ?) That question is the real, practical impact that we have to decide on. Everything else is hypothetical and achievable in this way or in other ways. But if we’re not willing to have a more inconsistent stdlib across our userbase, then the overall question seems to be moot, at least until Rust can be assumed to be as available as make+GCC. I’ll also note here that the SC has previously approved putting obviously core functionality on PyPI (subinterpreters), so until we rotate through to an entirely new SC, I don’t think there’s a case for “has to be in core” other than taking advantage of our popularity (which has been earned through stability, so we shouldn’t ruin it by actively destabilising it). ↩︎
ID: 277923
Author: James Webber
Created at: 2025-11-20T15:05:11.703Z
Number: 158
Clean content: Steve Dower: (which I assume it is, just unofficially for now - it doesn’t make any sense at all to “put Rust in CPython” without that ambition, since you can already write an extension module using Rust without our permission ). While I think some view that as an end goal, a PEP to allow Rust extensions in the stdlib still stands on its own merit–there should be a formal decision whether to allow that expansion. Even if the ultimate goal was “let some optional extensions be Rust” it would still need a PEP, no?
ID: 277924
Author: Jelle Zijlstra
Created at: 2025-11-20T15:05:24.571Z
Number: 159
Clean content: I like the idea of moving CPython towards Rust, but I feel the current proposal is so conservative that it doesn’t really get us there. The idea is to allow optional extension modules to be written in Rust. That basically means either new accelerators for modules currently written in Python, or completely new stdlib modules (which are rare). They have to be optional, which means that we must also maintain a Python (or C!) version, at least for existing modules. The concrete suggestion is base64 , which is currently fully in Python. The “optional” part means that this proposal will make the stdlib more inconsistent across users. There are many ways the stdlib is already inconsistent in this way, but I feel that’s generally a bad situation that we should avoid making worse: ideally, Python should be the same for all users, and users who use base64 shouldn’t have to think about the details of their platform to know its performance characteristics. There might be another unfortunate consequence. Clearly, lots of people are very excited about getting Rust in CPython. But with this proposal, the only realistic way they can do that is by adding new accelerator modules. Those could be for modules that already have a C accelerator, but in that case we have to keep the C version too to avoid creating a regression for users without Rust. Or it could be for modules that are currently fully in Python. But I’m not sure how many such modules there are for which an accelerator really makes sense: in most cases, if we’d wanted a C accelerator, we’d have written one already. Therefore, we might end up with Rust code that is mostly replacing Python code, not C code, and that isn’t terribly high-impact. To get safety wins from using Rust, we have to stop using C. Not necessarily everywhere, definitely not everywhere immediately, but at least somewhere. So for this proposal to be accepted, I feel there must be a clear path towards making it possible to replace existing C code with Rust, even if that means making Rust required.
ID: 277926
Author: Antoine Pitrou
Created at: 2025-11-20T15:17:04.475Z
Number: 160
Clean content: Jelle Zijlstra: So for this proposal to be accepted, I feel there must be a clear path towards making it possible to replace existing C code with Rust, even if that means making Rust required. IMHO that “clear path” must be conditioned on the bootstrap issues being solved. As in: bootstrapping CPython-with-Rust should not be harder than bootstrapping CPython-without-Rust. Once that happens, them I’m fully +1 for Rust in CPython, including core parts.
ID: 277927
Author: Steve Dower
Created at: 2025-11-20T15:17:17.891Z
Number: 161
Clean content: James Webber: While I think some view that as an end goal, a PEP to allow Rust extensions in the stdlib still stands on its own merit–there should be a formal decision whether to allow that expansion. Sure, but as I said in the rest of my post, that “formal decision” is really “can we let some people be lacking certain stdlib modules”. The choice of language is fairly orthogonal, since it isn’t going to affect the design of the runtime at all - we might as well bundle up C++ extension modules in the same PEP, since a similar number of users will be unable to use those, and some extension modules would benefit. Also, there’s only a small gap between “the stdlib may not have this module for you” and “if you want this module, choose to add it”. The latter is already possible with whatever language you want to use, so with the re-scoped proposal, we’re only slightly reframing things from the latter to the former. Once we’re officially okay with “the library is (core modules) plus (optional modules) plus (whatever your distro adds) plus (whatever you’ve installed)”, [1] then “optional modules” could be anything from anywhere (which means it’s really easy to say “yes, they could use Rust”). For explicitness, the current situation is “the library is (core modules) plus (whatever your distro adds) plus (whatever you’ve installed)”. The only thing we’re adding here is “optional modules”. ↩︎
ID: 277929
Author: Antoine Pitrou
Created at: 2025-11-20T15:25:43.096Z
Number: 162
Clean content: Steve Dower: we might as well bundle up C++ extension modules in the same PEP, since a similar number of users will be unable to use those, and some extension modules would benefit. I don’t think it would be the case. Everywhere you have a C compiler, you probably have a C++ compiler too.
ID: 277930
Author: Steve Dower
Created at: 2025-11-20T15:26:41.390Z
Number: 163
Clean content: Antoine Pitrou: I don’t think it would be the case. Everywhere you have a C compiler, you probably have a C++ compiler too. I agree, but I’m trying to be generous here We already have an (optional) C++ extension module in the stdlib, but don’t tell anyone.
ID: 277931
Author: Kirill Podoprigora
Created at: 2025-11-20T15:49:56.537Z
Number: 164
Clean content: Jelle Zijlstra: The concrete suggestion is base64 , which is currently fully in Python. In fact, base64 is built on top of the binascii module, which is implemented entirely in C. So I think you’re right, we can try replacing the current binascii implementation with a Rust-based one.
ID: 277935
Author: Xie Qi
Created at: 2025-11-20T16:34:23.668Z
Number: 165
Clean content: This post is about Rust, so it will attract considerable attention from Rust fans. As a result, most of the comments are likely to be positive (since they come from Rust fans). We still need to wait and see. but eventually will become a required dependency of CPython and allowed to be used throughout the CPython code base <del> Additionally, using Rust (which relies on LLVM) means abandoning many niche platforms.  Is this really an appropriate choice? Many popular open-source projects use Python to some extent.  If CPython drops support for certain platforms, those platforms will no longer be able to run many projects that depend on Python. That would be truly unfortunate! Rust may mitigate some memory-related issues, but… are you really in such a hurry to introduce Rust into CPython? In any case, Rust should be made optional. This way, maintainers of (Python-dependent) open-source projects can choose whether to use the Rust-dependent features or not. They deserve to have a choice! Moreover, making Rust a mandatory dependency for CPython sounds like a proposal driven by Rust fans to push their own agenda. </dev> Perhaps we can wait until the maturity of the following options: C++26: hardening and contract Zig gcc-rs After that, we can conduct more comparisons before making a final decision.
ID: 277939
Author: Filipe Laíns
Created at: 2025-11-20T16:52:42.002Z
Number: 166
Clean content: Thanks for pointing that out, that’s a great point. Personally, I thought of optionally introducing Rust more as a way to better understand how it would affect the community, and how well it would fit into the CPython codebase, and developers’ workflows. I also don’t see a great value from allowing Rust in optional modules purely from a maintainer perspective, but I think it is a necessary step to decide on making Rust a hard build dependency. That said, maybe someone else does have a use-case where Rust being available for optional components would be great. If that’s the case, it would be great to let us know
ID: 277955
Author: Stephan Sokolow
Created at: 2025-11-20T19:19:22.841Z
Number: 167
Clean content: shynur: Perhaps we can wait until the maturity of the following options: C++26: hardening and contract Zig gcc-rs Bear in mind that Zig isn’t aiming to serve the same niche as Rust as far as safety/correctness goes (See How (memory) safe is zig? for comparative details on its design philosophy) and posts like these suggest a worrying attitude toward Rust-level safety/correctness within the groups responsible for steering C++. On “Safe” C++ by Isabella “Izzy” Muerte Safe C++ proposal is not being continued by Simone Bellavia Why Safety Profiles Failed by Sean Baxter I’m having trouble remembering what I bookmarked it under so I can link it, but I’d also add the paper Stroustrup put out within the last few years which, to me at least, felt like a sign that the defensiveness various loud C++ developers feel toward the idea of Rust-like guarantees goes all the way to the top. (Which would be consistent with what On “Safe” C++ lays out.) I remember it being longer than A call to action: Think seriously about “safety”; then do something sensible about it .
ID: 277960
Author: Emma Smith
Created at: 2025-11-20T19:42:38.788Z
Number: 168
Clean content: Jelle Zijlstra: I like the idea of moving CPython towards Rust, but I feel the current proposal is so conservative that it doesn’t really get us there. You’re completely correct here, the pre-PEP does not get us to Rust being ubiquitous in CPython. I think we probably didn’t do a good enough job explaining why the approach is so conservative, and should explain more on a potential path to make Rust ubiquitous, so let me expand on that. I want to start by echoing @FFY00 Filipe Laíns: Personally, I thought of optionally introducing Rust more as a way to better understand how it would affect the community, and how well it would fit into the CPython codebase, and developers’ workflows. We intentionally want to keep the initial test as conservative as possible for a few reasons. Right now, the impact of introducing Rust at all is not fully known, so we want to make sure that it is both easy to back out of the change if it is untenable, and understand what workflows would break when Rust becomes required. One thing this thread has reinforced for me is that CPython is used all over the place, often in places we the core team are not aware of. The only way we can properly evaluate the potential impact of making Rust required is to start warning users we hope to do so and hear about places it would break, and what is needed to change to make Rust required. As for using Rust outside of extension modules, I think it could be used for experimental, opt-in interpreter features such as the JIT. I want to be cautious of this though because I don’t want the JIT to be in the state where it should become the default but making Rust required is a blocker to that. As everything else, it should be considered if migrating to Rust makes sense for the JIT. I’d also like to cite an article by Google researchers : There is a temptation, when introducing a new language, to pursue an aggressive timeline to justify the investment with short-term gains. Such an approach, fixated on overly ambitious goals, or rapid, sweeping change, invariably carries elevated risks of failure and can actively disincentivize future adoption by disrupting roadmaps and competing with other business objectives. A more powerful strategy, the one that proved so effective for Android, is to treat language adoption as a long-term investment in sustainable, compounding growth that supports other business objectives instead of competing with them. This approach patiently accepts initially lower absolute numbers to provide the necessary time for the new language to establish a foothold, build momentum, and achieve critical mass. In summary, for Android they found that moving to Rust is a long-term investment, that may not see immediate payoffs, but that moving to Rust is a long term success with significant payoffs. I realize this is a hard sell. But to me it makes a lot sense because there is a lot of learning and investigation to do related to integrating Rust into CPython. We need to spend the early period where Rust is allowed conservatively to build out the experience and support infrastructure for making Rust for CPython succeed. I could see a path where we start very conservatively with base64, then introduce a Rust version of a more central standard library module like json (as an optional replacement to the C version to start with), then make Rust required. But this is a guess at a plausible path forward, and the final path needs to be informed from experience. Jelle Zijlstra: in most cases, if we’d wanted a C accelerator, we’d have written one already. I would push back against this. One of the theses of this pre-PEP is that contributors are not inclined to write complex C code because it is difficult to do, thus projects like a C accelerator are not getting written. As an example, the performance of the json module has been significantly slower than other implementations for a long time. Yet a re-write in C would be daunting. I think Rust would excel in cases like this. Another example is actually the base64 module! `base64` module: Link against SIMD library for 10x performance. · Issue #124951 · python/cpython · GitHub We could use the Rust base64-simd crate for an easier, significant improvement to performance. Jelle Zijlstra: To get safety wins from using Rust, we have to stop using C. Not necessarily everywhere, definitely not everywhere immediately, but at least somewhere. Wholeheartedly agree with this, and that’s the goal with base64. We want to start somewhere , to better inform efforts elsewhere. Starting simply and minimally seems like the best path to allowing us to get an understanding without risk. Jelle Zijlstra: So for this proposal to be accepted, I feel there must be a clear path towards making it possible to replace existing C code with Rust, even if that means making Rust required. I think on the contrary we will see the greatest benefits for memory safety from making new code in Rust. A usenix paper found that the majority of vulnerabilities are in new code, as older code is battle-tested. So while I think we should enable replacing C code with Rust code where it makes sense, for example the json module, I think we will still see plenty of wins in new code too.
ID: 277965
Author: Jelle Zijlstra
Created at: 2025-11-20T20:04:14.019Z
Number: 170
Clean content: Emma Smith: I think on the contrary we will see the greatest benefits for memory safety from making new code in Rust. A usenix paper found that the majority of vulnerabilities are in new code, as older code is battle-tested. While most vulnerabilities may be in new code, I doubt they are in new modules . If we add a feature to (say) the JIT, or the JSON module, we have to write new C code.
ID: 277966
Author: Emma Smith
Created at: 2025-11-20T20:05:32.356Z
Number: 171
Clean content: Mark Shannon: What is the proposed API for rust? The section on implementation talks about using bindgen, but what is the underlying C API that you are binding? The limited API or the warts-and-all “unlimited” API? To interact with the interpreter today, we need to interface with C APIs. Currently the proof of concept binds to the unstable Python APIs as well as internal ones. We definitely want to build safe abstractions over the raw C APIs for common use cases, and that could perhaps use an API like handles. But it has to wrap the existing APIs like HPy does for CPython, so these necessarily need to be exposed to Rust. Mark Shannon: You mention PY_OBJECT_HEAD_INIT but that just couples rust code to the deep internals of the VM. To define a module, we need to have some way of defining a PyModuleDef, unless we want to introduce a new module initialization protocol (which is a large proposal in of itself). Therefore we need a pointer to a PyModuleDef, which needs it’s first member to be PyModuleDef_HEAD_INIT which internally expands to a structure with it’s first member being PyObject_HEAD_INIT. So some of this coupling is necessary as part of the module initialization protocol. Changing this protocol could be something we look into, but seems like it’s own rabbit hole 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.
ID: 277967
Author: Emma Smith
Created at: 2025-11-20T20:15:58.826Z
Number: 172
Clean content: Jelle Zijlstra: While most vulnerabilities may be in new code, I doubt they are in new modules . If we add a feature to (say) the JIT, or the JSON module, we have to write new C code. We absolutely need to write new C code for the JIT, the JSON module, or most other parts of CPython when making changes and adding features. However I think demanding immediate results across the code base from introducing Rust is infeasible. I’m curious as to your thoughts on the rest of my comment explaining why.
ID: 277968
Author: Jelle Zijlstra
Created at: 2025-11-20T20:18:44.330Z
Number: 173
Clean content: My thoughts are that a proposal that allows Rust only for optional extension modules is likely not useful enough to justify the cost of adding a new language. It can be a first step (in fact, it’s a very reasonable first step!), but that means there must be a plan to expand beyond it just being an optional part of building CPython. And that in turn means that we need to deal with the concerns that are being raised around bootstrapping and niche platforms.
ID: 277970
Author: Paul Moore
Created at: 2025-11-20T20:51:15.069Z
Number: 174
Clean content: Jelle Zijlstra: My thoughts are that a proposal that allows Rust only for optional extension modules is likely not useful enough to justify the cost of adding a new language. There’s been a number of comments about “optional extension modules” in this discussion so far. I want to make sure we’re 100% clear on what we mean by this, as I’m concerned we could end up measuring the wrong thing otherwise. As an end user, I have literally no interest in what language a stdlib module (or a core feature) is written in. It’s irrelevant to me. However, I have a strong interest in what is available in the stdlib and core. Optional modules are an awkward compromise here - can I use the module safely, or do I need to account for the possibility that it might not be available? This is exacerbated by the fact that the packaging ecosystem has no way to express a dependency on “Python >= 3.13, with the tkinter module available” (for example). If we introduce Rust by using it for stdlib modules, and as a result make them (and anything that depends on them!) optional, then we risk getting negative feedback which will look like it’s a downside of Rust, when it’s actually a downside of optional modules. I think the intention is not to do this, but rather to use Rust to create accelerators for existing pure-Python modules. But if that is the case, can we be clearer about this, so that people don’t get the wrong impression? Assuming we are talking about accelerators, I feel that @Jelle has a point. Using Rust to get a faster JSON module [1] will be a good way of finding out what’s involved in adding Rust to the core build process, but I don’t think it will provide much useful feedback on whether Rust provides sufficient benefit to be worth taking further. Which prompts the question - what would useful feedback look like? And how do we get it? I don’t think that’s been clearly established yet. I have to say that I don’t think anyone cares about a faster base64 module… ↩︎
ID: 277972
Author: Steve Dower
Created at: 2025-11-20T21:08:04.750Z
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.
ID: 277975
Author: Emma Smith
Created at: 2025-11-20T21:34:12.705Z
Number: 176
Clean content: Regarding optional extension modules, here’s a rough timeline I could see and why each step is chosen to be so. The goals of this stage are to get the initial build system changes set up, and start getting experience interfacing with the C code from Rust. Extension modules are a limited interface to the interpreter which minimizes the work to do for interoperability. Ideally we would also start warning users that we plan to eventually make Rust a hard requirement, and if this is a hardship for their environment, to please relate that to us. Only optional extension modules are allowed. Even more of a limitation, they should only be introduced where they would replace a C extension module (this could be things like base64 or json). The latter restriction exists to ensure we are not limiting access to new features to those who have Rust available. I picked the base64 module because it was simple but should exercise enough parts of the build system and C interop code, but we could just as well choose the json module. The goals of this stage are to make progress on improving portability and bootstrapping workflows based on feedback from stage 1. If we don’t gather feedback in stage 1 we could also start doing so here. More modules may be ported here to get even more experience with the C <—> Rust interfacing and overall developer experience. The goals of this stage are to ensure that we have resolved bootstrapping issues and warn of the impending requirement on Rust. Make Rust an opt-out feature of the interpreter. This is an even stronger warning of the up-coming requirement. At this point the vast majority of users should be able to build CPython with Rust enabled and bootstrapping issues should be resolved to greatest extent possible. I would say at this point new extension modules can be in Rust. The goal of this stage is to integrate Rust into core parts of CPython. Rust is required to build CPython. Rust can now be used across the CPython code base. This is one hypothetical scenario. We’re not going to propose this as the specification in the PEP. Jelle Zijlstra: My thoughts are that a proposal that allows Rust only for optional extension modules is likely not useful enough to justify the cost of adding a new language. It can be a first step (in fact, it’s a very reasonable first step!), but that means there must be a plan to expand beyond it just being an optional part of building CPython. There is simply too much to consider to resolve the bootstrapping and portability problems to have a concrete plan now . I think like PEP 703 did, we could leave an open question with some version of the above roadmap. But I don’t think we have enough information at the moment. The only way to tell what the impact of introducing Rust to CPython is to introduce Rust to CPython. In the above plan we start very conservatively to ensure we don’t break anyone’s workflows until we’re confident we can introduce Rust to core. I wouldn’t want to set hard timelines to any of this because we don’t know now when we should move to the next step in the process. So I think like free-threading, it would be best to start with step 1, then have a follow-up PEP when we are confident we have the information we need to move to the other steps.
ID: 277976
Author: James Webber
Created at: 2025-11-20T21:38:01.881Z
Number: 177
Clean content: 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. Surely this step was accomplished years ago, with the caveat that the Rust extensions aren’t usually “drop-in” replacements for an existing stdlib module, because that’s rarely what someone wanted to write. I don’t think anyone doubts that such a thing is possible, though? So what would be the next proposal after that?
ID: 277977
Author: Steve Dower
Created at: 2025-11-20T21:45:24.104Z
Number: 178
Clean content: James Webber: Surely this step was accomplished years ago Yeah, that’s my point. James Webber: So what would be the next proposal after that? Write one, prove it’s better, propose stdlib inclusion. It doesn’t even have to be a drop-in replacement, it can be a net-new module (but then the proposal needs to justify adding the module, which might make it too complicated). This is the standing process for adding something to the stdlib, and all that’s different is it’s the first proposal that would also bring in a new language. But then we are at least debating the merits in the context of something concrete, rather than something that feels very hypothetical.
ID: 277979
Author: James Webber
Created at: 2025-11-20T21:49:09.190Z
Number: 179
Clean content: I think that this is missing the point of this proposal, though. 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 [1] ”. that is, one that accelerates existing functionality ↩︎
ID: 277981
Author: James Webber
Created at: 2025-11-20T21:52:27.814Z
Number: 180
Clean content: That said–maybe it’s still too early for a PEP, and the real Proof-of-Concept is to set-up a full build? (edit: and the existing repo might be insufficient for that purpose if it doesn’t cover enough ground)
ID: 277982
Author: Emma Smith
Created at: 2025-11-20T21:53:16.786Z
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.
ID: 277984
Author: Steve Dower
Created at: 2025-11-20T21:55:32.028Z
Number: 182
Clean content: James Webber: The point is not “we really need a faster base64 , and specifically it should be written in Rust”. Sure, and the fact that we wouldn’t take this proposal seriously should also indicate that the lesser proposal of “we really need … Rust” isn’t going to be any more persuasive. On the other hand, “our drop-in replacement for json or re is 10x faster than the stdlib, can we merge it” is a far more interesting discussion to have. Emma Smith: Great! So then once we have a prototype of the abstraction your concerns will be assuaged? Probably not But my interest would be piqued by a production-ready replacement for an existing module, or a new module that we want in the stdlib anyway and the best way to get it is to bring in a Rust implementation.
ID: 277986
Author: Da Woods
Created at: 2025-11-20T22:05:04.216Z
Number: 183
Clean content: emmatyping: To define a module, we need to have some way of defining a PyModuleDef, unless we want to introduce a new module initialization protocol (which is a large proposal in of itself). Therefore we need a pointer to a PyModuleDef, which needs it’s first member to be PyModuleDef_HEAD_INIT which internally expands to a structure with it’s first member being PyObject_HEAD_INIT. So some of this coupling is necessary as part of the module initialization protocol. I think PEP 793 would disagree with this and probably be simpler from a Rust point of view because it doesn’t involve C macros (although that wasn’t the specific intent of it). (No comment on the larger context of the discussion…. just the specific paragraph)
ID: 277987
Author: Emma Smith
Created at: 2025-11-20T22:07:59.858Z
Number: 184
Clean content: Da Woods: I think PEP 793 would disagree with this and probably be simpler from a Rust point of view because it doesn’t involve C macros Fair point, and perhaps we should adopt PEP 793. I hadn’t realized the PEP was accepted, exciting!
ID: 277994
Author: Brénainn Woodsend
Created at: 2025-11-20T22:44:42.131Z
Number: 185
Clean content: Slightly tangential but I find optional stdlib components to be a menace and would really like their proliferation to be minimised. For pre-built Python installations like those on python.org or python-build-standalone , there’s nothing optional about them – someone will need them therefore they must be included therefore everyone gets them whether they’re needed or not. For those installing from source, it’s a footgun with remediation steps so platform specific that they can rarely even be written down in any detail. For those building Python for other people, it’s both. For distro-provided Python, it’s a surprise extra system dependency that rarely follows any predictable pattern and doesn’t correlate to anything in a lockfile. I’ve spent way more time debugging tkinter installations than even monster PyPI packages like Qt.
ID: 277998
Author: Emma Smith
Created at: 2025-11-20T22:55:14.403Z
Number: 186
Clean content: Brénainn Woodsend: Slightly tangential but I find optional stdlib components to be a menace and would really like their proliferation to be minimised. I have heard from a number of people a similar sentiment. I think therefore it’d be best if a new Rust module was a replacement for an existing C module that could act as a fallback, rather than an entirely new module with no fallback.
ID: 277999
Author: Brénainn Woodsend
Created at: 2025-11-20T23:01:38.607Z
Number: 187
Clean content: In that case, perhaps Python’s build system would have to be pushy and fail without rust by default unless some --use-legacy-c-{module}-implementation flag is given? Otherwise, I suspect that many of the people downstream we want feedback from aren’t going to notice it.
ID: 278001
Author: Neil Schemenauer
Created at: 2025-11-20T23:37:14.235Z
Number: 188
Clean content: I feel the current proposal is so conservative that it doesn’t really get us there. I think that’s okay.  This is going to be a many-year, perhaps on the order of decades, project.  The first step is to add Rust as an optional feature of the CPython build.  That will allow us to solve some tricky problems about how we can make Rust and C co-exist.  And, we can find out how many platforms are going to be affected by this (e.g. they can’t get the optional features to build) and fix that for as many platforms as we can. This initial step doesn’t necessarily help with code safety, API cleanliness, or performance aspects.  I’m sure others will disagree but, to me, the benefits that Rust can bring on those is clearly demonstrated in other projects.  We don’t need to prove those specifically for CPython. Edit: maybe it’s useful to enumerate what I think are the clear benefits that Rust could bring.  I’m not a Rust programmer so knowledgeable people will need to correct me if I’m wrong (as I’m sure they will gleefully do). array bounds checking: in the year 2025, it’s crazy we are using a programming language that doesn’t do this.  Yes, there can be extra overhead.  No, you are not smart enough to get it correct. use-after-free and other memory lifetime bugs.  Rust’s borrow checker avoids most of these at compile time. integer overflow: Rust doesn’t prevent it but at least it defines what happens.  Undefined behavior is bad. scope based cleanup: I’ve heard that the C language standard might eventually be getting something like __attribute__((cleanup(...))) .  It’s probably going to be decades before CPython could actually rely on C compilers supporting that.  This pattern comes up so often and it’s painful we don’t have a built-in language feature that supports it. There are other benefits and conveniences but these are the big ones, IMHO.
ID: 278011
Author: Jeong, YunWon
Created at: 2025-11-21T01:50:22.666Z
Number: 189
Clean content: nas: array bounds checking: in the year 2025, it’s crazy we are using a programming language that doesn’t do this. Yes, there can be extra overhead. No, you are not smart enough to get it correct. use-after-free and other memory lifetime bugs. Rust’s borrow checker avoids most of these at compile time. integer overflow: Rust doesn’t prevent it but at least it defines what happens. Undefined behavior is bad. scope based cleanup: I’ve heard that the C language standard might eventually be getting something like __attribute__((cleanup(...))) . It’s probably going to be decades before CPython could actually rely on C compilers supporting that. This pattern comes up so often and it’s painful we don’t have a built-in language feature that supports it. Adding more details about the points. array bounds checking is on by default, but when the overhead matters, explicitly skipping check is possible for each element access.. integer overflow panics on debug build. it has both checked operation and wrapping operation. checked operation is default on debug build. wrapping operation is default on release build. Of course each operation can be explicitly marked as checked if it is useful for runtime. Otherwise explicitly marking as wrapping is also useful when it is intended.
ID: 278013
Author: H. Vetinari
Created at: 2025-11-21T03:25:13.839Z
Number: 190
Clean content: Neil Schemenauer: I’ve heard that the C language standard might eventually be getting something like __attribute__((cleanup(...))) . It’s probably going to be decades before CPython could actually rely on C compilers supporting that. This is the defer proposal, which currently exists as a TS (like a branch of the C standard). Here’s an overview of the thing (and the procedural reasons for the TS) in blog post format. Clang has a mostly ready PR for this [1] . The GCC patch set is at v5 AFAICT. Long story short, this should be available in compilers relatively soon [2] and may make it into C2y if people like the feature and let people on the committee know. However you’re likely right about the timelines. Anything before 2040 for broad availability (i.e. defer as part of the standard, not a TS, and implemented across all major compilers present on LTS distros) would be wildly optimistic IMO [3] . Who knows how the world (and CPython) looks like by then… check out the number of reactions as a barometer for people’s interest in this ↩︎ MSVC’s C standard conformance has been horrible since C99; you’d be better off using clang-cl on windows than wait for MSVC on anything. They still haven’t gotten C99 or C11 finished, and ~zero for C23. ↩︎ On the other hand, if people were willing to replace MSVC with clang-cl and rely on -fdefer-ts , you could probably do it in 5 years, assuming the benefits are so substantial that this would be worth it. ↩︎
ID: 278044
Author: Antoine Pitrou
Created at: 2025-11-21T11:59:25.837Z
Number: 191
Clean content: Emma Smith: PyO3 already has 8 years of experience for us to steal re-use refining their APIs. You probably meant “borrow”.
ID: 278071
Author: Antoine Pitrou
Created at: 2025-11-21T19:51:28.905Z
Number: 192
Clean content: Ok, here’s a potential exercise if the optional module story isn’t appealing. The memoryview object is written in C and the performance of memoryview.index is currently horrid due to being written in a very naive way . Accelerating it in C involves generic programming in a language that doesn’t provide any decent metaprogramming. But if an alternate implementation of memoryview was written in Rust, then perhaps those accelerations would be much easier to implement (of course, you also need to develop some basic infrastructure for that: for example, a facility to dispatch to different generic specializations depending on the memoryview format ). So we could have an optional implementation of memoryview in Rust, and fallback on the C one on Rust-less platforms.
ID: 278155
Author: Emma Smith
Created at: 2025-11-22T18:11:23.522Z
Number: 193
Clean content: Thank you for bringing this up! I think memoryview could be a very appealing option for demonstrating Rust. Rust’s generics could make index a lot easier to implement as you say. I also think it has made me reconsider where to draw the line of where it is okay to re-write things in Rust. I want to start this by re-iterating that we do not want to go and just re-implement everything and anything in Rust to start with. At least until we have a lot more experience with Rust in CPython, and given contributors time to learn and try working with Rust, we should select up to a few experimental changes to make, and review our experiences after making those changes. Areas re-written in Rust should have a justification for doing so, like memoryview. We should also consider if the most active contributors to that portion of the codebase are comfortable with Rust being introduced. That being said I think we could expand where Rust could be implemented to include built-in objects, or really any part of the interpreter, if we also keep a C fallback of the implementation. For memoryview, we could keep the current implementation as a compile-time fallback and introduce a Rust version that takes advantage of it’s meta-programming (if needed) and generics. This may mean we’d need to maintain two versions of certain parts of the interpreter for a little while, but I think getting more experience across the code base would be worth the extra effort. The maintenance effort of keeping two implementations should be considered  as part of evaluating where to introduce Rust. With C compile-time fallbacks, there should be no cause for concern on portability or bootstrapping. This seems like a nice compromise between the very limited “Rust only in extension modules” and “Rust can go anywhere and we need to figure out bootstrapping”. Obviously the trade-off is maintenance burden, but I think if we’re smart about what parts we implement in Rust, we can minimize the effort. Curious what others think!
ID: 277474
Author: Emma Smith
Created at: 2025-11-17T16:14:10.092Z
Number: 1
Clean content: Introduction We ( @emmatyping , @eclips4 ) propose introducing the Rust programming language to CPython. Rust will initially only be allowed for writing optional extension modules, but eventually will become a required dependency of CPython and allowed to be used throughout the CPython code base (see update here about requiring Rust ). Motivation Rust has established itself as a popular, memory-safe systems programming language in use by a large number of projects. Memory safety is a property of a programming language which disallows out-of-bounds reads and writes to memory, as well as use-after-free errors. Rust’s safety properties are enforced by an ownership mode for code, which ensures that memory accesses are valid. Rust’s memory safety guarantees have been formally proven by the RustBelt project for code that does not use “unsafe” . By adopting Rust, entire classes of bugs, crashes, and security vulnerabilities can be eliminated from code. Due to Rust’s ownership model, the language also enforces thread safety: data races are prevented at compile time. With free-threaded Python becoming officially supported and more popular, ensuring the standard library is thread safe becomes critical. Rust’s strong thread safety guarantees would ease reasoning around multi-threaded code in the CPython code base. Large C/C++ based projects such as the Linux kernel , Android , Firefox , and many others have begun adopting Rust to improve memory safety, and some are already reporting positive results from this approach . Furthermore, Rust has become a popular language for writing 3rd-party extension modules for Python. At the 2025 Language Summit, it was mentioned that 25-33% of 3rd-party Python extension modules use Rust, especially new extension modules . By adopting Rust in CPython itself, we expect to encourage new contributors to extension modules. 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. While there will necessarily be some unsafe operations interacting with CPython’s C API to begin with, implementing the core module logic in safe Rust would greatly reduce the amount of code which could potentially be unsafe. Rust also provides “zero-cost”, well designed implementations of common data structures such as Vectors, HashMaps, Mutexes, and more. Zero cost in this context means that these data structures allow implementations to use higher-level constructs with the performance of hand-rolled implementations in other languages. The documentation for the Rust standard library covers these data structures very thoroughly. By having these zero-cost, high-level abstractions we expect Rust will make it easier to implement performance-sensitive portions of CPython. Rust additionally enables principled meta-programming through its macro system. Rust has two types of macros: declarative and procedural. Declarative macros in Rust are hygienic, meaning that they cannot unintentionally capture variables, unlike in C. This means it is much easier to reason about macros in Rust compared to C. Procedural macros are a way to write Rust code which does token transformations on structure definitions, functions, and more. Procedural macros are very powerful, and are used by PyO3 to ergonomically handle things like argument parsing, class definitions, and module definitions. Finally, Rust has an excellent build system. Rust uses the Cargo package manager , which handles acquiring dependencies and invoking rustc (the Rust compiler driver). Cargo supports vendoring dependencies out of the box, so that any Rust dependencies do not need to be downloaded (see open questions about dependencies). Furthermore, Rust has easy to set up cross-compilation which only requires installing the desired target and ensuring the proper linker is available. In summary, Rust provides many extremely useful benefits that would improve CPython development. Increasing memory safety would be a significant improvement in of itself, but it is far from the only benefit Rust provides. Implementation The integration of Rust would begin by adding Rust-based extension modules to the “Modules/” directory, which contains the C extensions for the Python standard library. The Rust modules would be optional at build time, dependent on if the build environment has Rust available. Integrating Rust with the CPython C API requires foreign function interface (FFI) definitions in Rust to describe the APIs available. A new crate (a library in Rust terminology) cpython-sys will be introduced to handle these FFI definitions. To automate the process of generating Rust FFI bindings, we use bindgen . Bindgen is not only an official Rust project, but also used ubiquitously throughout the Rust ecosystem to bind to C APIs, including in the Linux and Android projects. Bindgen uses libclang at build time to read C headers and automatically generate Rust FFI bindings for the current target. Unfortunately, due to the use of C macros to define some constants and methods, the cpython-sys crate will also need to replicate a few important APIs like PYOBJECT_HEAD_INIT manually. However these should all be straightforward to replicate and few in number. With the C API bindings available in Rust, contributors can call the FFI definitions to interact with CPython. This will necessarily introduce some unsafe Rust code. However extension modules should be written such that there is a minimal amount of unsafe at the edges of FFI boundaries. Eventually safe abstractions to simplify and standardize code like module definitions, function argument parsing, and class definitions could be adopted to reduce the amount of raw FFI code written. A reference implementation which includes a proof-of-concept _base64 module which uses Rust to provide a speedup to base64 is available. Distribution Rust supports all platforms which CPython supports and many more as well . Rust’s tiers are slightly different, and include information on whether host tools (such as rustc and cargo ) are provided. Here are all of the PEP 11 platforms and their corresponding tiers for Rust: Platform Python Tier Rust Tier aarch64-apple-darwin 1 1 with Host Tools aarch64-unknown-linux-gnu (gcc, glibc) 1 1 with Host Tools i686-pc-windows-msvc 1 1 with Host Tools x86_64-pc-windows-msvc 1 1 with Host Tools x86_64-unknown-linux-gnu (gcc, glibc) 1 1 with Host Tools aarch64-unknown-linux-gnu (clang, glibc) 2 1 with Host Tools wasm32-unknown-wasip1 2 2 without Host Tools x86_64-apple-darwin 2 2 with Host Tools x86_64-unknown-linux-gnu (clang, glibc) 2 1 with Host Tools aarch64-linux-android 3 2 without Host Tools aarch64-pc-windows-msvc 3 1 with Host Tools arm64-apple-ios 3 2 without Host Tools arm64-apple-ios-simulator 3 2 without Host Tools armv7l-unknown-linux-gnueabihf (Raspberry Pi, gcc) 3 2 with Host Tools aarch64-unknown-linux-gnu (Raspberry Pi, gcc) 3 1 with Host Tools powerpc64le-unknown-linux-gnu 3 2 with Host Tools s390x-unknown-linux-gnu 3 2 with Host Tools wasm32-unknown-emscripten 3 2 without Host Tools x86_64-linux-android 3 2 without Host Tools x86_64-unknown-freebsd 3 2 with Host Tools In summary, every platform Python supports is supported Rust at tier 2 or higher, and host tools are provided for every platform other than those where Python is already cross-compiled (e.g. WASI and mobile platforms). Rejected Ideas Use PyO3 in CPython While CPython could depend on PyO3 for safe abstractions over CPython C APIs, this may not provide the flexibility desired. If a new API is added to the C API, it would need to be added to PyO3, then the version of PyO3 would need to be updated in CPython. This is a lot of overhead and would slow down development. Using bindgen, new APIs are automatically exposed to Rust. Keep Rust Always-Optional Rust could provide many benefits to the development of CPython such as increased memory safety, increased thread safety, and zero-cost data structures. It would be a shame if these benefits were unavailable to the core interpreter implementation permanently. Open Questions How should we manage dependencies? By default cargo will download dependencies which aren’t already cached locally when cargo build is invoked, but perhaps we should vendor these? Cargo has built-in support for vendoring code. We could also cargo fetch to download dependencies at any other part of the build process (such as when running configure). How to handle binding Rust code to CPython’s C API? The MVP currently uses bindgen, which requires libclang at build time and a number of other dependencies. We could pre-generate the bindings for all supported platforms, which would remove the build-time requirement on vendoring bindgen and all of its dependencies (including libclang) for those platforms. When should Rust be allowed in non-optional parts of CPython? This section is out of date, please see Pre-PEP: Rust for CPython - #117 by emmatyping . Leaving the original for the record. Given the numerous advantages Rust provides, it would be advantageous to eventually introduce Rust into the core part of CPython, such as the Python string hasher, SipHash. However, requiring Rust is a significant new platform requirement. Therefore, we propose a timeline of: In Python 3.15, ./configure will start emitting warnings if Rust is not available in the environment. Optional extension modules may start using Rust In Python 3.16, ./configure will fail if Rust is not available in the environment unless --with-rust=no is passed. This will ensure users are aware of the requirement of Rust on their platform in the next release In Python 3.17, Python may require Rust to build We choose this timeline as it gives users several years to ensure that their platform has Rust available (most should) or otherwise plan for the migration. It also ensures that users are aware of the upcoming requirement. We hope to balance allowing time to migrate to Rust with ensuring that Rust can be adopted swiftly for its many benefits. How to handle bootstrapping Rust and CPython Making Rust a dependency of CPython would introduce a bootstrapping problem: Rust depends on Python to bootstrap its compiler . There are several workarounds to this: Rust could always ensure their bootstrap script is compatible with older versions of Python. Then the process is to build an older version of Python, build Rust, then build a newer version of CPython. The bootstrap script is currently compatible with Python 2, so this seems likely to continue to be the case Rust could use PyPy to bootstrap Rust could drop their usage of Python in the bootstrap process I ( @emmatyping ) plan to reach out to the Rust core team and ask what their thoughts are on this issue. What about platforms that don’t support Rust? Rust supports all platforms enumerated in PEP 11, but people run Python on other operating systems and architectures. Reviewing all of the issues labeled OS-unsupported in the CPython issue tracker, we found only a few cases where Rust would not be available: HPPA/PA-RISC: This is an old architecture from HP with the last released hardware coming out in 2005 and a community of users maintaining a Linux fork. There is no LLVM support for this architecture. RISC OS: This is a community maintained version of an operating system created by Acorn Computers. There’s no support in Rust for this OS. PowerPPC OS X: This older OS/architecture combination has a community of users running on PowerBooks and similar. There is no support in Rust for this OS/architecture combination, but Rust has PowerPC support for Linux. CentOS 6: Rust requires glibc 2.17+, which is only available in Centos 7. However, it is unlikely users on a no-longer-supported Linux distribution will want the latest version of CPython. Even if they do, CPython would have a hard time supporting these platforms anyway. How should current CPython contributors learn/engage with Rust portions of the code base? Current contributors may need to interact with the Rust bindings if they modify any C APIs, including internal APIs. This process can be well covered in the devguide, and there are many great resources to learn Rust itself. The Rust book provides a thorough introduction to the Rust programming language. There are many other resources in addition, such as Rust for C++ programmers and the official learning resources Learn Rust - Rust Programming Language . To ease this process, we can introduce a Rust experts team on GitHub who can be pinged on issues to answer questions about interacting with the API bindings. Furthermore, we can add a Rust tutorial focused on Rust’s usage in CPython to the devguide. Obviously any extension modules written in Rust will require knowledge of Rust to contribute to. What about Argument Clinic? Argument Clinic is a great tool that simplifies the work of anyone writing C functions that require argument processing. We see two possible approaches for implementing it in Rust: Adapt the existing Argument Clinic to parse Rust comments using the same DSL as in C extensions, and generate Rust function signatures. Create a Rust procedural macro capable of parsing a similar DSL. This approach might allow it to be used by any third-party package, whereas the C-based Argument Clinic does not guarantee compatibility with third-party extensions. Using a proc macro would allow for better IDE integration and could become useful to 3rd party extension authors. Should the CPython Rust crates be supported for 3rd-party use? Should there be a Rust API? Having canonical Rust crates for bindings to CPython’s C API would be advantageous, but the project is ill-prepared to support usage by 3rd-parties at this time. Thus we propose deferring making Rust code supported for 3rd-party use until a later date.
ID: 277475
Author: Cornelius Krupp
Created at: 2025-11-17T16:25:13.623Z
Number: 2
Clean content: Isn’t the experience in the linux kernel with adding rust support as a core part more a cautionary tale? At least it looks that way from the outside. There is constant friction between the two different “types of programmers”, causing a lot of quite public disagreement. If rust becomes a requirement for core devs, might that scare away some current maintainers who don’t want to deal with it?
ID: 277478
Author: Kirill Podoprigora
Created at: 2025-11-17T16:32:54.743Z
Number: 3
Clean content: Hello, and thanks for your question! We will try to make this transition as smooth as possible. We’re planning to write a “migration guide” for CPython contributors to help make their adoption of Rust as easy as possible. Can this scare current maintainers? Yes. Will we do everything we can to make sure it doesn’t? Absolutely.
ID: 277480
Author: Jacopo Abramo
Created at: 2025-11-17T16:45:22.507Z
Number: 4
Clean content: I’m not a core dev nor expert in the internals of CPython, but I wanted to chime in to resonate with the question from @MegaIng , pointing out though that it looks to me (as a Python user) that the community in general is more “approachable” in comparison to what happened during the integration of some Rust in the Linux kernel. Out of curiosity, what would this mean for both PyO3 and RustPython ? Have you reached out to the mantainers of the latter for feedback on how to approach this possibility? If so, what’s their opinion? It looks to me like this possible PEP might benefit greatly from their experience (I don’t know if you guys are part of their team, I’m just assuming you’re not but I apologize if that’s incorrect). Also, I’m probably jumping the gun with this question, but since also RustPython seems to be implementing the GIL in a similar fashion, would you expect some challenges in applying PEP 703 efficiently for rust-based extensions? I imagine (or rather, hope) that by the time 3.17 is out that CPython will be completely GIL-less by then. Do you expect that this additional feature will be provided smoothly in Rust extensions as well? Same question applies for the new experimental JIT which should be more stable in future releases. Finally, if I recall rust applications tend to be a bit “bloated” in binary size, although there are some tricks that can be done at compile time to reduce this - what do these tricks imply on performance I have no idea.
ID: 277482
Author: Steve Dower
Created at: 2025-11-17T17:04:41.634Z
Number: 5
Clean content: As a general direction, I’d rather see “optional extension modules” [1] living outside the main repo and brought in later in the build/release process. Presumably such modules have no tight core dependency, or they wouldn’t be able to be optional, and so they should be able to build on pre-release runtimes and work fine with released runtimes (as we expect of 3rd party developers). The bootstrapping position is discussed in the proposed text and determined to be viable. I think this position applies equally well to bootstrapping the modules we theoretically expect people to write that rely on non-core dependencies. Merging in additional modules as part of our release process is fine. Bundling additional sources and optional build steps into the source tarball is fine (if we think that Linux distros will just ignore us when we say “you should include these modules in your Python runtime”). For what it’s worth, I believe that the parts of CPython that directly depend on OpenSSL and Tcl/Tk are also fit for this. So don’t see my position as being about Rust itself [2] - it’s about the direction we should be taking with adding new modules to the core runtime. In short, adding new ways to add new, non-essential modules to the core is counter to the approach we’ve been taking over the last few years. So I’m -1 on adding one. Also optional regular modules. ↩︎ If you want my position about Rust itself, well… it’s not going to help your PEP at all ↩︎
ID: 277483
Author: Alex Gaynor
Created at: 2025-11-17T17:05:59.850Z
Number: 6
Clean content: As I think many folks know, I’ve been quite involved in these sorts of efforts (starting the effort that became Rust for Linux at the PyCon sprints, migrating pyca/cryptography to Rust, and helping to maintain pyo3). As a result, it will come to no one’s surprise that I’m very supportive of this pre-PEP I’m happy to answer any questions folks have about those experiences and lessons learned.
ID: 277485
Author: James Webber
Created at: 2025-11-17T17:17:51.836Z
Number: 7
Clean content: As a Rust fan I think this is super cool! I do wonder if this is too much to figure out in one PEP, when parts of it seems pretty easily separable. I can see how the overall vision fits together, but it’s a lot. Would it make sense to restrict the initial proposal as just “create the cpython-sys crate and allow optional Rust extensions in the stdlib”? That would allow iteration on making a good generic interface [1] without requiring the SC to make a decision on the long-term plan. there is plenty of prior art in PyO3 , and I think the HPy project has some relevance there too ↩︎
ID: 277487
Author: Michael H
Created at: 2025-11-17T17:31:19.898Z
Number: 8
Clean content: I would feel more comfortable with this if it was dependent on custom json targets stabilizing in Rust. Right now, targetting platforms that Rust itself doesn’t support still requires nightly, and python is used to bootstrap a lot of things in a lot of places. I don’t think the impact of this is going to be reasonably predictable, and I’d want there to be a stable upstream escape hatch for those in unusual situations.
ID: 277489
Author: Gundarin Roman
Created at: 2025-11-17T18:17:44.410Z
Number: 9
Clean content: Doesn’t “C“ in the name of “CPython“ means “C programming language”? If so, shouldn’t the project be eventually renamed when a significant part of it is (re)written in Rust? /joke, but who knows
ID: 277490
Author: Da Woods
Created at: 2025-11-17T18:38:53.354Z
Number: 10
Clean content: I’ll start by saying my opinion doesn’t matter here: the number of lines of C I’ve written that’s in the Python interpreter is of the order of 10, so whatever you decide it’s unlikely to be my personal problem. I’m pretty convinced of Rust as a nice language to write cool new things in (and of the value of exposing cool those cool new things to be used from Python). I’m less convinced of the benefit of rewriting existing working things in Rust. [1] So from my point of view this PEP doesn’t offer a lot - it’s largely proposing “rewrite some modules in Rust with a view to soften people up to rewrite more in Rust”. I’d be much more convinced by a PEP that wanted to add something useful to the standard library and had found the best way to do that was to use a Rust library. Minor comment: emmatyping: Rust could use PyPy to bootstrap I suspect this isn’t viable for a couple for reasons: PyPy isn’t hugely well maintained right now, and (I believe) PyPy needs a Python interpreter to bootstrap itself so may not solve the problem. And I think some of the push-pack Rust gets is from when people do this. It’s hard to argue with the benefit of a new and exciting feature but easy to be unimpressed with “what we already have but in Rust”. ↩︎
ID: 277491
Author: Antoine Pitrou
Created at: 2025-11-17T18:48:33.079Z
Number: 11
Clean content: Emma Smith: Eventually safe abstractions to simplify and standardize code like module definitions, function argument parsing, and class definitions could be adopted to reduce the amount of raw FFI code written. A reference implementation which includes a proof-of-concept _base64 module which uses Rust to provide a speedup to base64 is available. This example shows that you really want the safe abstractions for this to be useful. Otherwise you’re doing the same kind of tedious, unsafe, error-prone low-level pointer juggling and manual reference cleanup as in C (hello Py_DecRef ).
ID: 277493
Author: Guido van Rossum
Created at: 2025-11-17T19:06:36.769Z
Number: 12
Clean content: Snarky note: do we eventually have to rename CPython to CRPython? Seriously, I think this is a great development. We all know that a full rewrite in Rust won’t work, but starting to introduce Rust initially for less-essential components, and then gradually letting it take over more essential components sounds like a good plan. I trust Emma and others to do a great job of guiding the discussion over the exact shape that the plan and the implementation should take.
ID: 277494
Author: Nathan Goldbaum
Created at: 2025-11-17T19:13:14.690Z
Number: 13
Clean content: As a PyO3 maintainer IMO it’d be really nice if we could get rid of the need for the pyo3-ffi crate and instead rely on bindgen bindings maintained by upstream. Most of the overhead of supporting new Python versions is updating the FFI bindings. I bet @davidhewitt has opinions about this from the PyO3 maintainer perspective and I’ll defer to him if he disagrees with me about pyo3-ffi .
ID: 277495
Author: Ed Page
Created at: 2025-11-17T19:18:19.754Z
Number: 14
Clean content: emmatyping: How to handle bootstrapping Rust and CPython Making Rust a dependency of CPython would introduce a bootstrapping problem: Rust depends on Python to bootstrap its compiler . There are several workarounds to this: Rust could always ensure their bootstrap script is compatible with older versions of Python. Then the process is to build an older version of Python, build Rust, then build a newer version of CPython. The bootstrap script is currently compatible with Python 2, so this seems likely to continue to be the case Rust could use PyPy to bootstrap Rust could drop their usage of Python in the bootstrap process I ( @emmatyping ) plan to reach out to the Rust core team and ask what their thoughts are on this issue. The specific team involved is T-bootstrap which you can reach out to on zulip at #t-infra/bootstrap
ID: 277496
Author: Chris Angelico
Created at: 2025-11-17T19:18:26.061Z
Number: 15
Clean content: Guido van Rossum: Snarky note: do we eventually have to rename CPython to CRPython? I would strongly advise against that, on account of people inserting an “A” into it More seriously though: Rust has been a focus for a lot of controversy and risk, with massive open questions such as the impact of a potential Ken Thompson style compiler hack . Will CPython lose trust by becoming dependent on a single specific compiler that might be subject to such a hack? Currently, CPython can be compiled using multiple different compilers (I believe gcc, clang, and MSVC are all supported - correct me if I’m wrong?), which mitigates the threat by allowing them to check each other. Adding Rust to the mix will mean that, on every platform, the same Rust compiler MUST be used.
ID: 277497
Author: Paul Ganssle
Created at: 2025-11-17T19:41:22.635Z
Number: 16
Clean content: I have long liked the idea of doing something like this, and as someone who always introduces memory leaks and segfaults and such any time he writes any kind of C extension code, I welcome the idea of more modern zero-cost abstractions for that [1] . However, one cost I think that has not been mentioned here is the effect that this could have on build times. In my experience, compile times for Rust (and C++) are much slower than for C. On my 2019 Thinkpad T480, from a fresh clone of CPython, I can build the whole thing in 2m50s (with make -j , and admittedly it taxes the machine): real	2m50.573s
user	14m57.260s
sys	0m42.975s After the initial build, incremental builds are in seconds. Not sure I know of any projects of comparable size and complexity to compare with, does anyone know if (in the extreme — I know this isn’t the plan) we were to re-write CPython in Rust, how the build times would compare? I really think that the fast iteration time and low overhead from the builds is a great feature of our current build system that I would really hate to give up. I guess the question is a dual one: can we write Rust in a way that it will not cause build times to explode and if we cannot, is the plan to keep the scope of Rust in CPython to a level where building is still very accessible? My thinking is that if build times were 2x slower that would be acceptable if it meant a significant reduction in security critical bugs, but I personally wouldn’t love it if it were much slower than that. On rereading, I realized that this makes it sound like I want zero-cost abstractions to help me introduce more segfaults. If it’s unclear to anyone, I meant “to avoid that”. I have left the original wording because I like to at least initially convey that I am Chaotic Neutral. ↩︎
ID: 277499
Author: Barry Warsaw
Created at: 2025-11-17T19:51:57.260Z
Number: 17
Clean content: Guido van Rossum: Snarky note: do we eventually have to rename CPython to CRPython? Clearly it should be “CrustyPython” But seriously, I’m really excited about this proposal.
ID: 277500
Author: James Webber
Created at: 2025-11-17T19:55:18.227Z
Number: 18
Clean content: In my experience incremental Rust builds are also very fast–the initial setup (including downloading and building all the dependencies) can be slow, but it’s able to do fast incremental builds just fine. Also, there’s a big difference between debug and release mode–building in debug mode is way faster. I would be surprised if this impacted iteration time unless you’re trying to rebuild the world every time.
ID: 277502
Author: danny mcClanahan
Created at: 2025-11-17T20:32:02.439Z
Number: 19
Clean content: I recently elected to try learning C++ after an entire professional career of Rust + Python, because I wanted to make a build system that can be bootstrapped in as few jumps as possible (so that it could be invoked from inside other build systems like cargo or pip). Having worked a lot on the pants build tool in python + rust, I have strong feelings about affordances the build system should provide to users—feelings I will try to quell to achieve a productive discussion. The pants build tool has incorporated rust since Twitter’s “moonshot” rewrite from python-only through 2017-2019—I contributed the current iteration of our python-level interface for cacheable+parallelizable build tasks ( Concepts | Pantsbuild ), which uses pyo3 to hook up rust async methods as “intrinsics” which can be interchanged with “async def” coroutines (Stu Hood originally proposed and implemented this approach)—we’ve had this interop since before async was stable and before pyo3 existed. We used rust, so we had to use cargo. Most of a decade later, we haven’t managed to use our own build system (written in rust) to build the rust code at the heart of our system. I claim that one of the major reasons for this failure is that cargo is almost unique among build systems in providing absolutely no structured mechanisms for: (1) communicating with other package build scripts in the same dependency graph (2) communicating with the downstream user who invokes cargo (such as a distro packager, or a github actions pipeline) This failure is especially notable because of the same powerful guarantees cargo ensures for rust-only dependency graphs, as described in OP: Finally, Rust has an excellent build system. Rust uses the Cargo package manager, which handles acquiring dependencies cargo unfortunately has no standard mechanism for declaring dependencies downloaded within a build script so that they can be audited or overwritten, except the excessively restricted (non-transitive) and poorly documented links key in Cargo.toml, which requires that a build script link a native library into the resulting executable. cargo also has no standard conception of a “toolchain”, or even an ABI outside of rustc output. This can and does mean that build scripts will fail because a dependency was built for a slightly different ABI, because again, not only is there no standard interface for downstream build configuration, but there’s not even a standard interface for communicating structured data across build scripts . So rust devs end up doing the natural thing and using somewhere in ~/.cache or ~/.config or elsewhere as undocumented mutable state. I am relatively confident this isn’t an oversimplification, because bootstrapping the rust compiler itself ends up invoking multiple distinct reimplementations of LLVM target triple parsing, added at different times and never synced up. This is because rustc uses cargo, and cargo does not support structured communication across build scripts. I proposed some of how I wanted to help improve this situation to NGI Zero at the end of last year. This C++ system I mentioned at the beginning is a competing approach, which would replace cargo instead of attempting incremental reform. I’m still not sure of the “right” answer to this—and I don’t think fixing cargo should be the purview of this PEP anyway. But I am personally convinced that if CPython were to integrate rust (possibly even just at phase 1, with only external module support), we (CPython and pypa contributors, of which I am only the latter) would necessarily have to figure out a more structured way to thread ABI info through cargo, and potentially even institute a whole structured communication mechanism across the build script dependency graph. I think that will be a lot of hard work and we should prepare for it earlier rather than later . I am very heartened to read in OP that there are steps being taken to interface with the rustc team to express CPython’s bootstrapping+portability requirements. It sounds like we’re on a good trajectory already to consider the above. I would just urge contributors to consider that pants has not solved cargo’s python packaging difficulties in many years and that it may be worth opening up a greater discussion about cargo affordances in order for cargo (not just rustc) to support CPython’s (and consequently pypa’s) needs.
ID: 277503
Author: Alex Gaynor
Created at: 2025-11-17T20:40:32.388Z
Number: 20
Clean content: pganssle: I guess the question is a dual one: can we write Rust in a way that it will not cause build times to explode and if we cannot, is the plan to keep the scope of Rust in CPython to a level where building is still very accessible? The best things we can do to keep Rust build UX good for core devs (and other contributors): Keep a lean dep tree – and be able to rebuild each module individually (lots of parallelism, like we have in C). Have a easy to use flow that uses cargo check , which does type checking but doesn’t actually compile, since that gives you a very fast devloop.
ID: 277504
Author: David Hewitt
Created at: 2025-11-17T20:43:30.183Z
Number: 21
Clean content: Thank you @emmatyping @eclips4 for proposing this (and @ngoldbaum for the ping)! Very excited to see this initiative and as a proponent of Python, Rust, and the two together, eager to be involved. As a longtime PyO3 maintainer I have been thinking about what this might look like for a while. I asked about exactly this kind of possibility at the Language Summit earlier this year to gauge the temperature for anyone wishing to experiment. The response I heard then was that experimentation towards a concrete proposal was welcome (I hadn’t yet found the time to explore myself, so thank you). I have a number of comments so will try to keep each brief for now and we can expand later if needed. emmatyping: [rejected] Use PyO3 in CPython pitrou: This example shows that you really want the safe abstractions for this to be useful. I completely agree with both of these points. Depending on PyO3 as currently implemented within CPython will introduce unwanted friction. PyO3 also supports PyPy and GraalPy, as well as older versions of CPython (currently back to 3.7). Rust for CPython will presumably not need to support anything other than current CPython. At the same time, CPython will need safe higher-level Rust APIs to get the benefit of Rust. PyO3 has a lot of prior art on the high-level APIs (and hard lessons learned); I think the right approach here will be similar to what attrs did for dataclasses - the Rust APIs implemented by CPython can pick the bits that work best. emmatyping: What about platforms that don’t support Rust? gccrs is an alternative implementation of Rust for GCC backend, which is not yet at feature parity but an important target for Rust for Linux. If CPython was using Rust, I would hope that efforts for non-llvm platforms may be helped by this. emmatyping: What about Argument Clinic? PyO3’s proc macros function a lot like argument clinic - we could potentially reuse parts of their design (and/or implementation); PyO3 might eventually even depend upon any implementation owned by CPython. I would recommend this choice as the more idiomatic way to do codegen in Rust. emmatyping: Should the CPython Rust crates be supported for 3rd-party use? Should there be a Rust API? ngoldbaum: As a PyO3 maintainer IMO it’d be really nice if we could get rid of the need for the pyo3-ffi crate and instead rely on bindgen bindings maintained by upstream. Most of the overhead of supporting new Python versions is updating the FFI bindings. I agree with both of these points; we may want some experience before deciding how CPython would want to commit to supporting these crates. At the same time, having a way to consume in-dev CPython versions immediately in PyO3 would really help with iteration speed for the ecosystem. PyO3 has precedent of “experimental” features for things not yet stable, one middle ground might be to allow PyO3 to have an experimental feature which switches out pyo3-ffi ’s curated FFI bindings for the ones generated by CPython. MegaIng: Isn’t the experience in the linux kernel with adding rust support as a core part more a cautionary tale? At least it looks that way from the outside. There are a couple of takeaways from Rust for Linux that I think are most interesting here: Social questions - inevitably not everyone will want to be using \<insert language X here\>  instead of \<insert language Y here\>. Some current maintainers might churn from not wanting Rust, and other new maintainers may be attracted by the appeal of using it. The Python community places a lot of emphasis on inclusivity and I’d hope we would welcome everyone’s opinions as valid even if eventually a decision driven by the majority must be taken. (Not implying here whether the majority is for or against exploring Rust support; that is the purpose of having these discussions, after all.) Technical opening - Rust for Linux has unsurprisingly become a major strategic focus for the language. I would hope that Rust for CPython would have justification for carrying similar weight in the focus of the Rust project should there be friction where Rust (and cargo etc) do not currently meet CPython’s needs.
ID: 277505
Author: Emma Smith
Created at: 2025-11-17T20:50:49.739Z
Number: 22
Clean content: Note: I’m working on replying to everyone but wanted to get some initial replies out, I appreciate patience with this. Cornelius Krupp: Isn’t the experience in the linux kernel with adding rust support as a core part more a cautionary tale? At least it looks that way from the outside. There is constant friction between the two different “types of programmers”, causing a lot of quite public disagreement. I agree with @jacopoabramo on this, I like to think that the Python community will be better about being productive, amicable, and respectful when discussing these issues. So I think the experience will be altogether different. Jacopo Abramo: Out of curiosity, what would this mean for both PyO3 and RustPython ? Have you reached out to the mantainers of the latter for feedback on how to approach this possibility? If so, what’s their opinion? It looks to me like this possible PEP might benefit greatly from their experience (I don’t know if you guys are part of their team, I’m just assuming you’re not but I apologize if that’s incorrect). I reached out to David Hewitt who has now responded in this thread and will contribute to the effort (thank you, David!) . Kirill has reached out to the RustPython team as well! Jacopo Abramo: would you expect some challenges in applying PEP 703 efficiently for rust-based extensions? On the contrary, it should be much less effort as safe Rust is thread-safe due to the borrow checker. There will need to be some support added to handle integrating attached thread states, but it should be relatively easy. Jacopo Abramo: Same question applies for the new experimental JIT which should be more stable in future releases. Sorry, I’m not sure if you are asking if Rust extensions will work with the JIT or if Rust can be used to implement it? For the former they should work without issue. For the latter the JIT currently relies on a custom calling convention which is not yet exposed in Rust (but is being discussed to do so last I checked). I don’t suggest moving this code to Rust until it is reasonable to implement in Rust and the necessary calling convention features are available. Jacopo Abramo: Finally, if I recall rust applications tend to be a bit “bloated” in binary size, although there are some tricks that can be done at compile time to reduce this - what do these tricks imply on performance I have no idea. This is definitely something to be cognizant of, thank you for bringing it up! There are several strategies which will not affect performance, such as abort on panic, which we can explore. We will probably want to abort on panic anyway since unwinding over FFI layers is UB. Steve Dower: As a general direction, I’d rather see “optional extension modules” living outside the main repo and brought in later in the build/release process. Presumably such modules have no tight core dependency, or they wouldn’t be able to be optional, and so they should be able to build on pre-release runtimes and work fine with released runtimes (as we expect of 3rd party developers). I think this is an interesting proposal, but orthogonal to the current one. We hope Rust will eventually become required to build CPython so it can be used to improve the CPython core. I would suggest splitting this off into it’s own thread to discuss it further. Steve Dower: In short, adding new ways to add new, non-essential modules to the core is counter to the approach we’ve been taking over the last few years. So I’m -1 on adding one. Again I think it is important to highlight that this proposal is more than just _base64 , and more than just optional modules. We’d eventually like to make Rust a hard dependency so it can be used to improve the implementation of the Python runtime as well. Alex Gaynor: I’m happy to answer any questions folks have about those experiences and lessons learned. Thanks Alex! We definitely want to approach this carefully and with thought, your expertise will be invaluable! James Webber: As a Rust fan I think this is super cool! I do wonder if this is too much to figure out in one PEP, when parts of it seems pretty easily separable. I can see how the overall vision fits together, but it’s a lot. I think we necessarily need to make a plan for long term adoption so we can figure out when Rust can be a required dependency and ensure we plan ahead in advance well enough for it. I don’t want to get anyone caught by surprise when suddenly they need Rust to build CPython when they don’t expect it. I will say that the final PEP will probably be what you propose plus a timeline to make Rust a required dependency. Iterating on ergonomic APIs for Rust is definitely something I’d be working on if cpython-sys is approved. Michael H: I would feel more comfortable with this if it was dependent on custom json targets stabilizing in Rust. Right now, targetting platforms that Rust itself doesn’t support still requires nightly, and python is used to bootstrap a lot of things in a lot of places. Perhaps then we can ensure that releases build with an older nightly Rust to enable such bootstrapping? I expect these cases to be relatively uncommon - Rust supports a large number of platforms. Da Woods: So from my point of view this PEP doesn’t offer a lot - it’s largely proposing “rewrite some modules in Rust with a view to soften people up to rewrite more in Rust”. I would restate our goal as “slowly introduce Rust to carefully integrate it and make sure we get things right and give people time to adapt to the significant change.” _base64 is chosen as an example as it is easier to implement, easier to understand, and would only affect performance, so is entirely optional. I think there are several existing modules that could see clear benefits from being written in Rust, eventually . Especially for those that interact with untrusted input such as json, it would be a significant improvement security-wise if we implemented them in a memory safe language. But I also don’t want to rush in and cause breakage. These kinds of changes should be done carefully and when well-motivated. Da Woods: emmatyping: Rust could use PyPy to bootstrap I suspect this isn’t viable for a couple for reasons: PyPy isn’t hugely well maintained right now, and (I believe) PyPy needs a Python interpreter to bootstrap itself so may not solve the problem. Good point re PyPy requiring some bootstrap Python itself! I hope that the approach of using an older CPython will be workable. Antoine Pitrou: emmatyping: A reference implementation which includes a proof-of-concept _base64 module which uses Rust to provide a speedup to base64 is available. This example shows that you really want the safe abstractions for this to be useful. Otherwise you’re doing the same kind of tedious, unsafe, error-prone low-level pointer juggling and manual reference cleanup as in C (hello Py_DecRef ). I absolutely agree, safe abstractions over things like argument parsing and module creation make PyO3 a joy to use. I hope we can collaborate with the PyO3 maintainers and provide similarly pleasant abstractions in CPython core. It will certainly be a high priority. I do think even in this simple example there are examples of safe abstractions that provide benefits. Kirill wrote up an abstraction over borrowing a Py_buffer that automatically releases the buffer on drop, so that it is impossible to forget to do that and cause a bug: cpython/Modules/_base64/src/lib.rs at c9deee600d60509c5da6ef538a9b530f7ba12e05 · emmatyping/cpython · GitHub Guido van Rossum: Seriously, I think this is a great development. We all know that a full rewrite in Rust won’t work, but starting to introduce Rust initially for less-essential components, and then gradually letting it take over more essential components sounds like a good plan. I trust Emma and others to do a great job of guiding the discussion over the exact shape that the plan and the implementation should take. Thank you Guido for your trust and words of support, it really means a lot!
ID: 277506
Author: Jubilee
Created at: 2025-11-17T20:51:47.620Z
Number: 23
Clean content: Speaking in a broad way to answer a broad (“depends on many details”) question: In C, the primary compilation unit is each individual file. In Rust, the primary compilation unit is each entire crate. Rust offers many conveniences over C (e.g. not needing to “forward declare” things in various files) that depend on the fact it can treat crates as individual units. As a result, if you were to, for instance, compare the two languages based on “files compiled” but one is a crate, the results may be surprising. But with thoughtful (or just arbitrary) splitting of code, Rust does allow you to keep iterative builds relatively fast, especially if all the code you haven’t changed is in crates upstream of the one you changed. Paying attention to this is especially important for the -sys crates containing bindings, as bindgen essentially involves running a compiler to generate code and thus is not cheap. It’s worth noting that C also enjoys faster compilation with careful management of inclusions and include-guards on repeatedly-included headers. There are many caveats, exceptions, and and-alsos one can attach to what I just said when things get more specific. Some Rust idioms will not make it faster to build something, due to e.g. use of generics or #[inline] that requires multiple downstream instantiations in multiple downstream crates. And of course there’s ongoing work here, such as relink, don’t rebuild , where some of us are attempting to make it so changes to upstream crates only cause rebuilds of downstream crates if the upstream crate actually changed its public API.
ID: 277507
Author: James Gerity
Created at: 2025-11-17T20:54:20.059Z
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.
ID: 277508
Author: Steve Dower
Created at: 2025-11-17T20:55:04.476Z
Number: 25
Clean content: Emma Smith: We’d eventually like to make Rust a hard dependency so it can be used to improve the implementation of the Python runtime as well. Then you force me to factor in my experience in Rust, my experience in mixed-language codebases, and my experience in teams, and come down as a firm -1 on the entire proposal.
ID: 277509
Author: David Hewitt
Created at: 2025-11-17T20:56:39.913Z
Number: 26
Clean content: emmatyping: On the contrary, it should be much less effort as safe Rust is thread-safe due to the borrow checker. There will need to be some support added to handle integrating attached thread states, but it should be relatively easy. I completely agree with this; my experience of updating Rust code based upon PyO3 to support free-threaded Python has been relatively painless. I would even go further and suggest that Rust for CPython may be able to assist with the implementation of free-threaded Python; if there are current stlib extension modules needing to be updated for PEP 703 which lack maintainers, migrating them to Rust may be a way to bring on new maintainers and get them thread-safe at the same time. emmatyping: We will probably want to abort on panic anyway since unwinding over FFI layers is UB. For what it’s worth, PyO3 has a mechanism for carrying panics as Python exceptions through stack frames, but I would agree that for sake of binary size and simplicity, an abort would be good enough (the Rust panic hook could be configured to call into Python’s existing fatal exit machinery).
ID: 277512
Author: Steven Sun
Created at: 2025-11-17T21:07:59.873Z
Number: 27
Clean content: In my previous job, I developed and maintained a large codebase mixing C++, Python, and Rust. I am very familiar with these 3 languages. You can notify me if new Rust code or docs requires review. I support if we can start with some extensions with C/Python fallback. Based on my experience, I want to highlight that certain common practice do not align with Rust. For example, fork() is not usable for many Rust libraries (states may be incorrect after fork). https://stackoverflow.com/questions/60686516/why-cant-i-communicate-with-a-forked-child-process-using-tokio-unixstream
ID: 277513
Author: Dmitry
Created at: 2025-11-17T21:17:46.637Z
Number: 28
Clean content: It’s been such an exciting time for Python lately, with this proposal, lazy imports and frozendicts! Another benefit that you might want to mention in the PEP is how IIUC this would open the door for the possibility of shipping with Python modern Rust-based tooling for dep management, formatting and linting, with all the performance, correctness and community enthusiasm that comes with it.
ID: 277516
Author: Emma Smith
Created at: 2025-11-17T21:38:45.101Z
Number: 29
Clean content: Chris Angelico: More seriously though: Rust has been a focus for a lot of controversy and risk, with massive open questions such as the impact of a potential Ken Thompson style compiler hack . Will CPython lose trust by becoming dependent on a single specific compiler that might be subject to such a hack? I’m not familiar with the risks you speak of. As David Hewitt points out, there is a work in progress implementation using gcc, so while there is currently one compiler, that will not remain the case. Paul Ganssle: I guess the question is a dual one: can we write Rust in a way that it will not cause build times to explode and if we cannot, is the plan to keep the scope of Rust in CPython to a level where building is still very accessible? I mostly will defer to @workingjubilee ’s excellent answer and their expertise. I will add however that build times are dear to my heart, so I think good devguide documentation on setting up a dev environment that is configured for fast incremental builds will go a long way in helping. danny mcClanahan: But I am personally convinced that if CPython were to integrate rust (possibly even just at phase 1, with only external module support), we (CPython and pypa contributors, of which I am only the latter) would necessarily have to figure out a more structured way to thread ABI info through cargo This is a really interesting perspective, thanks Danny! I will say getting cargo to fit into CPython’s current build system was a little tricky. That being said I think the ABI question may be less important until Rust code is exposed to users, which will be after we’ve had a lot of experience working with cargo ourselves and can be planned independently of the initial integration, in collaboration with PyPA. David Hewitt: Very excited to see this initiative and as a proponent of Python, Rust, and the two together, eager to be involved. Very excited to have you join us! We greatly value your expertise on Rust and Python interop. David Hewitt: At the same time, CPython will need safe higher-level Rust APIs to get the benefit of Rust. PyO3 has a lot of prior art on the high-level APIs (and hard lessons learned); I think the right approach here will be similar to what attrs did for dataclasses - the Rust APIs implemented by CPython can pick the bits that work best. This is right along the lines of what I was thinking, so glad we are on the same page David Hewitt: emmatyping: What about platforms that don’t support Rust? gccrs is an alternative implementation of Rust for GCC backend, which is not yet at feature parity but an important target for Rust for Linux. If CPython was using Rust, I would hope that efforts for non-llvm platforms may be helped by this. Excellent point! We should make sure to note this in the PEP. David Hewitt: emmatyping: What about Argument Clinic? PyO3’s proc macros function a lot like argument clinic - we could potentially reuse parts of their design (and/or implementation); PyO3 might eventually even depend upon any implementation owned by CPython. I would recommend this choice as the more idiomatic way to do codegen in Rust. Absolutely, I think this would be a great path forward. I would love if the code could be shared across PyO3 and CPython! David Hewitt: Technical opening - Rust for Linux has unsurprisingly become a major strategic focus for the language. I would hope that Rust for CPython would have justification for carrying similar weight in the focus of the Rust project should there be friction where Rust (and cargo etc) do not currently meet CPython’s needs. Yes, there will likely be a few things upstream that may need some work but probably (hopefully!) less than Linux! James Gerity: 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. If you look at issues labeled type-crash you will see a number of issues, such as Use-after-free due to race between SSLContext.set_alpn_protocols and opening a connection · Issue #141012 · python/cpython · GitHub or heap-buffer-overflow in pycore_interpframe.h _PyFrame_Initialize · Issue #140802 · python/cpython · GitHub or JSON: heap-buffer-overflow in encoder caused by indentation caching · Issue #140750 · python/cpython · GitHub . There are many more. James Gerity: ”What will we do about doubling the number of programming languages in the core” feels important to address up-front. Absolutely, I hope that thorough devguide coverage and good tooling will go a long way in making this experience pleasant. I also think having a team of experts will be useful. James Gerity: It seems to me that an eventual PEP should address ”Why not put that development effort towards RustPython ?” in the Rejected Ideas section Thanks, will add this to the list of rejected ideas to add. I also want to cover other language choices, and a few other things. James Gerity: 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. Hm, what adjustment did you have in mind? Steve Dower: Then you force me to factor in my experience in Rust, my experience in mixed-language codebases, and my experience in teams, and come down as a firm -1 on the entire proposal. I’m sorry to hear that Steve. I’m happy to chat further about your experiences at some point, there are definitely wrong ways of integrating new languages into existing code bases. David Hewitt: For what it’s worth, PyO3 has a mechanism for carrying panics as Python exceptions through stack frames, but I would agree that for sake of binary size and simplicity, an abort would be good enough (the Rust panic hook could be configured to call into Python’s existing fatal exit machinery). That’s good to know! I think we will have to evaluate this (as with many things) and decide based on what our experience finds out. Steven Sun: You can notify me if new Rust code or docs requires review. I support if we can start with some extensions with C/Python fallback. Thanks Steven! It’s been great to see a number of people excited about contributing to CPython in Rust if it were added. Steven Sun: Based on my experience, I want to highlight that certain common practice do not align with Rust. For example, fork() is not usable for many Rust libraries (states may be incorrect after fork). https://stackoverflow.com/questions/60686516/why-cant-i-communicate-with-a-forked-child-process-using-tokio-unixstream fork() + threads is sadness pretty universally, it has been an issue for CPython before, so it’s an issue I’m well aware of. Thanks for bringing it up! Dmitry: Another benefit that you might want to mention in the PEP is how IIUC this would open the door for the possibility of shipping with Python modern Rust-based tooling for dep management, formatting and linting, with all the performance, correctness and community enthusiasm that comes with it. That’s a good point, I’ll make sure to note that in the PEP. I misunderstood this post I think, see my comment below.
ID: 277517
Author: James Gerity
Created at: 2025-11-17T21:41:18.108Z
Number: 30
Clean content: emmatyping: Hm, what adjustment did you have in mind? Nothing in particular. 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.
ID: 277519
Author: Chris Angelico
Created at: 2025-11-17T21:49:50.295Z
Number: 31
Clean content: Emma Smith: Rosuav: More seriously though: Rust has been a focus for a lot of controversy and risk, with massive open questions such as the impact of a potential Ken Thompson style compiler hack . Will CPython lose trust by becoming dependent on a single specific compiler that might be subject to such a hack? I’m not familiar with the risks you speak of. As David Hewitt points out, there is a work in progress implementation using gcc, so while there is currently one compiler, that will not remain the case. The risk, in short, is that rustc could easily include all kinds of code that isn’t obvious to an outside auditor. Ken Thompson demonstrated this using a hack that created a login back door; the same thing could infect a more modern system by secretly downgrading TLS in some way, making it possible for a third party to snoop supposedly-encrypted connections. Perhaps in the future this won’t be as much of a consideration, but that would be then, and this is now. Right now, how can we trust rust? How can we know that a Ken Thompson-style hack hasn’t already been done? How do we ensure that one won’t happen in the future? These are not merely academic questions. Python is a well-trusted language used extensively across the internet; if someone with a strong agenda decided to target it, it would be an absolute catastrophe, not least because of how insidious it would be.
ID: 277520
Author: Kirill Podoprigora
Created at: 2025-11-17T21:52:03.542Z
Number: 32
Clean content: @davidhewitt Hi David, and thank you very much for maintaining pyo3! I have a question that we should probably address in the PEP: Can we integrate MIRI into our workflow? Have you tried using it in pyo3, and what were the results? TL;DR: MIRI is an undefined-behavior detection tool for Rust, so I’m guessing it could be helpful for us
ID: 277525
Author: Paul Moore
Created at: 2025-11-17T22:00:39.369Z
Number: 33
Clean content: Chris Angelico: Right now, how can we trust rust? How can we know that a Ken Thompson-style hack hasn’t already been done? How do we ensure that one won’t happen in the future? These are not merely academic questions. It seems to me that adoption of Rust for various other core system components offers some level of assurance here. While there are still risks, it seems likely that they would be discovered relatively quickly as Rust adoption increases. Particular cases I’m thinking of include: Rust in the Linux kernel The Rust reimplementation of coreutils being adopted for Ubuntu Microsoft including Rust in the Windows kernel While the risk involved in a single compiler implementation remains, the chance of detecting any consequent compromise seems like it’s going to rapidly decrease as projects like the above become more widespread.
ID: 277527
Author: Chris Angelico
Created at: 2025-11-17T22:05:19.866Z
Number: 34
Clean content: Paul Moore: It seems to me that adoption of Rust for various other core system components offers some level of assurance here. While there are still risks, it seems likely that they would be discovered relatively quickly as Rust adoption increases. That means that the potential attack surfaces are many. It doesn’t make the decision right for any other project. To be quite honest, I have these exact same concerns regarding the Rust rewrites elsewhere; but (for example) a Rust-based sudo would require that someone first gain shell access as a non-privileged user, and THEN be able to wield an exploit embedded in sudo. With something that is key to many web sites and other internet-connected services, the attack potential is far more direct. Paul Moore: While the risk involved in a single compiler implementation remains, the chance of detecting any consequent compromise seems like it’s going to rapidly decrease as projects like the above become more widespread. And that would be a strong protection, if the only type of attack were one that hits everything all at once. Unfortunately, as Ken Thompson’s hack proved, this sort of attack can be extremely narrowly targeted. And Python is a juicy target.
ID: 277528
Author: James Webber
Created at: 2025-11-17T22:08:01.407Z
Number: 35
Clean content: Is any language really safe from this? Surely gcc alone is a hugely valuable target for such an attack–how do we know it hasn’t happened? Heck, how do we know it hasn’t happened in CPython ? It seems like this is a separate security discussion that goes far beyond Rust.
ID: 277531
Author: Steven Sun
Created at: 2025-11-17T22:10:45.966Z
Number: 36
Clean content: Rosuav: The risk, in short, is that rustc could easily include all kinds of code that isn’t obvious to an outside auditor. I want to add that this risk is real. Besides the code in rust compiler, Rust support procedural macro which executes user-written code during compilation. It requires a lot of work to fully audit. This happened in Rust community before. One previous event is a well-used library shipping pre-built binary to accelerate procedural macro without notice, causing many worries from users. github.com/serde-rs/serde using serde_derive without precompiled binary opened 11:39PM - 27 Jul 23 UTC closed 03:50PM - 17 Aug 23 UTC decathorpe I'm working on packaging serde for Fedora Linux, and I noticed that recent versi … ons of serde_derive ship a precompiled binary now. This is problematic for us, since we cannot, under *no* circumstances (with only very few exceptions, for firmware or the like), redistribute precompiled binaries.

Right now the fallback I am trying to apply for the short-term is to patch serde_derive/lib.rs to unconditionally include lib_from_source.rs (we don't really care about compilation speed for our non-interactive builds).

I'm wondering, how is the x86_64-unknown-linux-gnu binary actually produced? The workspace layout in this project looks very differently from when I last looked in here ... Would it be possible for us to re-create the binary ourselves so we can actually ship it? Or would it be possible to adapt the serde_derive crate to fall back to the non-precompiled code path if the binary file is missing? Rosuav: how can we trust rust? How about a switch to turn off all rust code?
ID: 277532
Author: Chris Angelico
Created at: 2025-11-17T22:11:36.188Z
Number: 37
Clean content: James Webber: Is any language really safe from this? Surely gcc alone is a hugely valuable target for such an attack–how do we know it hasn’t happened? Heck, how do we know it hasn’t happened in CPython ? The biggest protection is having multiple compilers. Do you want to make sure your gcc hasn’t been infected? Download the source code for gcc, and compile it using clang. This could also be affected, but only if someone has infected BOTH compilers. The more diffferent options there are, the less of a threat this is. The threat is, by definition, only relevant to compiled languages that compile their own compilers. It’s inherent in the bootstrapping. So this can’t happen in CPython as it currently is, unless there’s some way that Python code is being used to generate future versions of the CPython binary, in a way that’s independent of the source code (eg Argument Clinic can’t be that, because the output is right there for everyone to see).
ID: 277534
Author: Steve Dower
Created at: 2025-11-17T22:17:33.902Z
Number: 38
Clean content: I’ll briefly put my security team hat on and say that the security side of this is being way overblown. The risk of a supply-chain attack via the compiler is miniscule compared to the multitude of other options - adding Rust doesn’t make that part worse. 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).
ID: 277536
Author: Emma Smith
Created at: 2025-11-17T22:30:00.207Z
Number: 39
Clean content: Chris Angelico: The biggest protection is having multiple compilers. Do you want to make sure your gcc hasn’t been infected? Download the source code for gcc, and compile it using clang. This could also be affected, but only if someone has infected BOTH compilers. The more diffferent options there are, the less of a threat this is. Given that clang had to be bootstrapped by gcc, I think it is impossible to say that this will work for sure. Steve Dower: I’ll briefly put my security team hat on and say that the security side of this is being way overblown. The risk of a supply-chain attack via the compiler is miniscule compared to the multitude of other options - adding Rust doesn’t make that part worse. Thanks Steve! I appreciate you piping up on this. 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 I have a couple of thoughts on this, and hope @davidhewitt has more since he has thought about this problem probably a lot more than I have First, we can build safe abstractions over unsafe operations which will reduce the amount of unsafe users need to interact with. Furthermore, I expect to start with, a safe core for extension modules can be implemented then exposed to CPython through unsafe FFI procedures. This is an approach that has seen wide success throughout other projects. One of Rust’s strengths is that it allows you to focus on where unsafety occurs. Finally, if more of the interpreter were to become Rust, these portions would presumably have safe Rust interfaces.
ID: 277537
Author: Guido van Rossum
Created at: 2025-11-17T22:31:09.753Z
Number: 40
Clean content: steve.dower: Then you force me to factor in my experience in Rust, my experience in mixed-language codebases, and my experience in teams, and come down as a firm -1 on the entire proposal. Steve, without more details your -1 has no weight. You can’t just argue from authority .
ID: 277538
Author: Aria Desires
Created at: 2025-11-17T22:32:52.963Z
Number: 41
Clean content: 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). I highly recommend reading the article from the Android Security team that the original post linked . In particular, the article focuses on a “near-miss” where they almost shipped one (1) memory safety vulnerability in Rust: This near-miss inevitably raises the question: “If Rust can have memory safety vulnerabilities, then what’s the point?” The point is that the density is drastically lower. So much lower that it represents a major shift in security posture. Based on our near-miss, we can make a conservative estimate. With roughly 5 million lines of Rust in the Android platform and one potential memory safety vulnerability found (and fixed pre-release), our estimated vulnerability density for Rust is 0.2 vuln per 1 million lines (MLOC) Our historical data for C and C++ shows a density of closer to 1,000 memory safety vulnerabilities per MLOC. Our Rust code is currently tracking at a density orders of magnitude lower: a more than 1000x reduction. … The primary security concern regarding Rust generally centers on the approximately 4% of code written within unsafe{} blocks. This subset of Rust has fueled significant speculation, misconceptions, and even theories that unsafe Rust might be more buggy than C. Empirical evidence shows this to be quite wrong. Our data indicates that even a more conservative assumption, that a line of unsafe Rust is as likely to have a bug as a line of C or C++, significantly overestimates the risk of unsafe Rust. We don’t know for sure why this is the case, but there are likely several contributing factors: unsafe{} doesn’t actually disable all or even most of Rust’s safety checks (a common misconception). The practice of encapsulation enables local reasoning about safety invariants. The additional scrutiny that unsafe{} blocks receive. I totally understand the concern but there’s so many big old C(++) projects that have integrated Rust and “safety of the bindings” is an obvious concern everyone has and it just… doesn’t end up being that big of a deal in practice? In practical specific terms, it’s often reported that Rust often makes implicit ownership/lifetime constraints in C APIs explicit and easier to work with. The Rust bindings to C functions can include lifetimes that enforce these contracts (and yes a lot of C APIs map onto lifetimes and ownership well).
ID: 277539
Author: Steve Dower
Created at: 2025-11-17T22:33:10.734Z
Number: 42
Clean content: Guido van Rossum: Steve, without more details your -1 has no weight I’m aware. Happy to chat more with the people interested in driving this forward or evaluating/deciding on it, but there are more than enough opinions here already and I don’t see mine helping drive the discussion forward in any particularly meaningful way (especially given the response to my “keep it contained” concern was “actually, we’re going to make it less contained”).
ID: 277540
Author: William Woodruff
Created at: 2025-11-17T22:34:06.482Z
Number: 43
Clean content: Steven Sun: Besides the code in rust compiler, Rust support procedural macro which executes user-written code during compilation. It requires a lot of work to fully audit. It’s worth noting that Rust’s compile-time code execution (via build.rs ) closely mirrors the style and trust model already assumed by Python packaging (via setup.py ). I’m not extremely familiar with the history of build.rs , but it wouldn’t especially surprise me if setup.py (and Gemfile , etc.) were used as a reference point. (I also think the risk of compile-time code execution in Rust is narrow compared to what already exists: how often do you read the autoconf that your C and C++ dependencies use to codegen shell scripts at build time? We have empirical evidence in the form of xz-utils that attackers find that very appealing!)
ID: 277546
Author: Steven Sun
Created at: 2025-11-17T23:03:19.329Z
Number: 44
Clean content: Still a few important questions: Who will lead this large-scale refactoring? 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?
ID: 277553
Author: Donghee Na
Created at: 2025-11-18T00:01:37.746Z
Number: 45
Clean content: I am basically neutral on adopting Rust, and I think Ruby provides a good reference model. They introduced Rust for their JIT implementation as an optional component, and it is worth studying how they approached. (only using std-lib, except unittest and unittest module are excluded when they release) However, I am cautious about the idea of fully rewriting the CPython codebase in Rust. We have a lot of low level and very optimized C code that Rust cannot express safely. A good example is the computed goto dispatch in the interpreter, which would require a large amount of unsafe code or inline assembly if we tried to reproduce it in Rust. Platform support is also still a concern, and that’s why people are waiting for gcc-rs , because once it is shipped, we can cover over where gcc and clang do. My view is that if we want to move forward, we should begin with an experimental approach. We can start by introducing new, non-essential modules written in Rust and evaluating the results. That feels like a reasonable and safe first step, and it allows us to focus on productivity rather than framing everything around memory safety. 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. From what I understand, the Ruby team adopted Rust mainly because implementing their JIT in Rust was more productive than doing it in C. I think that was one of the major factors behind their choice.
ID: 277554
Author: Jeong, YunWon
Created at: 2025-11-18T00:02:42.657Z
Number: 46
Clean content: People still remember the huge drama from early 2025, but I think we should pay more attention to what Torvalds and Greg K-H recently said at the Open Source Summit Korea just two weeks ago. So, so that’s that’s one thing that has changed for me is that I actually feel like sometimes I need to encourage some of the other maintainers to be more open to to new ideas. If we want to bring up Rust for Linux as an example, we should not only talk about how introducing a new and unfamiliar idea can create conflict among existing maintainers, but also emphasize that leadership plays a role in encouraging the community to embrace such changes.
ID: 277557
Author: Brett Cannon
Created at: 2025-11-18T00:32:57.514Z
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.
ID: 277558
Author: Emma Smith
Created at: 2025-11-18T00:37:14.443Z
Number: 48
Clean content: Brett Cannon: sunmy2019: 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. Brett Cannon: sunmy2019: 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. I agree with everything Brett says above, but also wanted to add that I am going to spend some time over the next few days on community building around Rust in CPython with a goal of kicking off discussions around a lot of the topics brought up here.
ID: 277559
Author: Barry Warsaw
Created at: 2025-11-18T00:45:01.991Z
Number: 49
Clean content: Donghee Na: However, I am cautious about the idea of fully rewriting the CPython codebase in Rust. I would go further and predict that this will never happen, and claim that it shouldn’t be a goal of the Rust-in-Python project.  There are 10**oodles of person-years invested in the CPython core interpreter, and I just don’t see how that will ever be cost effective to rewrite, even as a Ship of Theseus . But that’s not to say we shouldn’t go forward with this experiment, because we’ll better understand the costs and benefits [1] . One of the soft consequences I’m especially interested in is whether this attracts more or fewer core developers contributing to the Rust bits than the C bits.  I don’t remember the numbers, but I vaguely recall some discussion about the number of core devs who are comfortable contributing to the C bits vs the Python bits.  The former is surely a smaller number, and my guess is that even fewer are comfortable in Rust today [2] . and better know the unknown unknowns ↩︎ To be clear, I consider everyone’s contributions, regardless of where or what language, to be incredibly valuable and valued ↩︎
ID: 277560
Author: Emma Smith
Created at: 2025-11-18T00:53:59.811Z
Number: 50
Clean content: Donghee Na: We have a lot of low level and very optimized C code that Rust cannot express safely. A good example is the computed goto dispatch in the interpreter, which would require a large amount of unsafe code or inline assembly if we tried to reproduce it in Rust. I think this is actually a great example where Rust could be a huge improvement over C. There is  interest in the Rust community to implement a safe state machine loop, e.g. this proposal RFC: Improved State Machine Codegen by folkertdev · Pull Request #3720 · rust-lang/rfcs · GitHub . That proposal may not get into Rust, but given the interest I am sure there will be some safe solution implemented eventually. And I would like to re-iterate another point: we absolutely should not re-write things that don’t make sense to. The core interpreter loop itself may not make sense to for a while, but that doesn’t mean other important runtime things can’t be Rust, like thread state management, the parser, and others. Barry Warsaw: I would go further and predict that this will never happen, and claim that it shouldn’t be a goal of the Rust-in-Python project. Well then you’ll be really glad with this blurb I was writing in response to Donghee’s post . Speaking for myself here: The goal of this project should not specifically be to re-write CPython in Rust, but rather iteratively move more C code to Rust over time and reap the benefits for those portions of code. This may end up meaning Python becomes entirely Rust! But I don’t think that will necessarily be the end goal. Barry Warsaw: One of the soft consequences I’m especially interested in is whether this attracts more or fewer core developers contributing to the Rust bits than the C bits. I’m also quite interested in this! Given that we have seen people shifting to Rust for new 3rd-party extension modules I really hope that will translate into more contributors.
ID: 277561
Author: Alex Gaynor
Created at: 2025-11-18T00:59:01.064Z
Number: 51
Clean content: emmatyping: The goal of this project should not specifically be to re-write CPython in Rust, but rather iteratively move more C code to Rust over time and reap the benefits for those portions of code. One thing I do think is worth saying: The highest ROI pieces are going to be modules and perhaps builtin types/functions, which can be implemented entirely in safe Rust with ergonomics high level APIs, reaping performance and developer experience/velocity wins. Something like the GC is at the absolute nadir of the value of Rust: it inevitably requires a decent amount of unsafe and won’t benefit from Rust’s other advantages. And then many other things (e.g., the parser or interpreter loop) are likely to be in the middle in terms of where I’d estimate the ROI is.
ID: 277562
Author: Donghee Na
Created at: 2025-11-18T01:15:27.824Z
Number: 52
Clean content: emmatyping: but that doesn’t mean other important runtime things can’t be Rust, brettcannon: 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. Just to clarify: I love using Rust, and I’m one of the people interested in bringing Rust into CPython. I’ve talked about this topic in the context of JIT because of its practical advantages. @emmatyping What I’m curious about is this: in the current PoC, most of the code uses unsafe blocks. I understand this isn’t Rust’s fault but rather a limitation of the CPython API. Still, how do these modules become memory-safe in the PoC, and how much less do we need to worry about memory safety compared to writing the same code in C? For example, if you could say something like “X% of the code in the base64 module becomes memory-safe,” that would be a helpful metric to highlight. Also, do you have any plans to remove the unsafe blocks in modules like base64 ? If so, could you include that plan in the PEP? Another thing: could you compare build times and performance between the C version (with PGO + LTO) and the Rust build? I think that would make the PEP much more balanced and fair for reviewers.
ID: 277563
Author: Neil Schemenauer
Created at: 2025-11-18T01:19:41.409Z
Number: 53
Clean content: Alex Gaynor: Something like the GC is at the absolute nadir of the value of Rust: it inevitably requires a decent amount of unsafe and won’t benefit from Rust’s other advantages. Based on my recent experience in adding hardware prefetch to the free-threaded GC, I feel like writing in Rust could have provided some good benefit.  For example, implementing the gc_span_stack_t data structure and associated methods would have been easier to write and to review.  I would expect that it also would have prevented this memory leak bug in that code.
ID: 277565
Author: Emma Smith
Created at: 2025-11-18T01:47:21.059Z
Number: 54
Clean content: Donghee Na: What I’m curious about is this: in the current PoC, most of the code uses unsafe blocks. I understand this isn’t Rust’s fault but rather a limitation of the CPython API. Still, how do these modules become memory-safe in the PoC, and how much less do we need to worry about memory safety compared to writing the same code in C? I think this section covers that: Emma Smith: Eventually safe abstractions to simplify and standardize code like module definitions, function argument parsing, and class definitions could be adopted to reduce the amount of raw FFI code written. The current implementation is really a proof of concept, so there are a lot of places it could improve. It started with myself wishing to see how hard it would be to integrate Rust with cargo into our existing build system. A Rust _base64 module in CPython will look a bit different from the current proof of concept I hope. I expect extension modules will likely be able to be to be 80% safe hand-written code or more. That being said, building out the safe abstractions will take time and effort to do properly. So I think I would say, if you want to see something like where I hope to end up, look at PyO3, where the vast majority of hand written code is safe. Donghee Na: Another thing: could you compare build times and performance between the C version (with PGO + LTO) and the Rust build? I think that would make the PEP much more balanced and fair for reviewers. @Eclips4 found that his hand-rolled implementation that does not use any SIMD is about 1.6x faster than the _binascii implementation in use today. It’s hard to make a “fair” compilation speed benchmark because there are many variables that can come into play and knobs that can be tuned. The added Rust code will also necessarily add more compile time because we aren’t removing code by introducing _base64 .
ID: 277566
Author: Brénainn Woodsend
Created at: 2025-11-18T01:51:41.667Z
Number: 55
Clean content: Will the binaries written in rust be able to share a single copy of dependencies and/or the rust runtime? My recollection is that ABI in rust is a forgotten dream and that each library/ or executable ends up with separate copy of all its dependencies plus a big fat core runtime lumped into it, turning a network of little libraries [1] into a network of bloatware. But it’s a long time since my last (unsuccessful) attempt to get into rust so that might no longer be true (assuming that it was ever true). or extension modules in CPython’s case ↩︎
ID: 277567
Author: William Woodruff
Created at: 2025-11-18T02:04:28.924Z
Number: 56
Clean content: Brénainn Woodsend: Will the binaries written in rust be able to share a single copy of dependencies and/or the rust runtime? My recollection is that ABI in rust is a forgotten dream Rust has no problem using the C ABI; from experience, the norm when integrating Rust into existing C codebases is retain existing ABI boundaries and perform dynamic linking in the same ways that the codebase would normally. (There’s a separate issue, which is that fully separate Rust builds tend to prefer static linkage because there’s no stable Rust ABI. But the integration efforts of Chrome, Firefox, etc. are good examples of integration of Rust components into projects that assume the C/C++ ABIs.)
ID: 277571
Author: Jeong, YunWon
Created at: 2025-11-18T02:25:14.462Z
Number: 57
Clean content: Hi, I’m one of the RustPython developers, and during work hours I maintain a tightly-coupled C++/Rust project of about 200k lines. I’d like to comment on some of the points raised in the post and the thread. I’m still getting used to Discourse, so please excuse me about missing quotes. Questions about RustPython RustPython isn’t something that can be considered in this PEP in short term. RustPython and CPython are not semantically compatible across many layers of their implementation. Well, RustPython has a bunch of pure Rust library with excellently working Python stdlibs. it could serve as a reference when introducing Rust versions of certain libraries. I don’t believe it is directly related to this PEP. RustPython has its own approach to running without a GIL, but it’s not compatible with CPython’s nogil direction. 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. bindgen I think there must be a good guidelines on how bindgen should be used. bindgen generates both data structure definitions and function bindings. Function bindings are usually reliable—but data structure definitions often are not. If we rely on bindgen for those, we must run the generated tests to verify compatibility. 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’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. Though while rust-in-cpython focuses on writing stdlib modules, where C doesn’t need to call Rust, there may be limited motivation to use cbindgen. This perspective comes from my experience with mixed C++/Rust projects. CPython being a C/Rust project may lead to fewer issues. clinic 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. When Rust penetrates deeper than the module boundary and this approach breaks down, we’ll have better insight for future decisions anyway. ABI I’m not sure how far Rust implementation will expand, but compared to Pants, CPython’s requirements seem much simpler. If we connect this with the clinic/cbindgen idea, we could enforce a policy that every exported symbol must be declared in a properly generated C header. Since the only stable ABI in Rust is the C ABI, having headers fully specify remains reasonable until Rust APIs are officially exposed to users. Build time Ideally, Rust debug builds shouldn’t be too slow. But many Rust libraries lean heavily on proc-macros, which can significantly impact build times. For example, RustPython has far less code and functionality than CPython, yet it takes ~5× longer to build, and the gap is even bigger for incremental builds. If build time is a major concern, guidelines limits unnecessary proc-macro usage may help. Also, on the external tooling side, we can hope llvm might support faster Rust debug builds later since Python is a priority project for llvm project. I don’t worry about generics in rust-in-cpython. Unlike RustPython, rust-in-cpython must generate C interface, which discourage to abuse generics. From a build-time perspective, keeping one crate per module as _base64 doing now is very appealing. Using unsafe In my opinion, completely eliminating unsafe from base64 isn’t the right goal. Rust guarantees that code outside an unsafe {} block is safe. Anything the compiler cannot verify must be wrapped in unsafe {} . Wrapping unsafe internals in a “safe” API means the programmer is manually guaranteeing safety. Some guarantees can be established through review and careful implementation, but FFI safety often cannot be fully guaranteed due to inherent interface limitations. 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. So instead of trying too hard to remove unsafe , it’s better to encourage properly mark actually unsafe code and minimize them when possible. Rust benefits vs. FFI cost Rust reduces memory-related bugs, but across FFI boundaries, things can actually become less safe than using a single C compiler. The more FFI boundaries exist, the more type information is lost, and the more binding risk increases. Usually, early Rust adoption increases FFI surface area and reduce problems in the rust codebase but also creates new problems at the same time. Then over time, as Rust takes over more internals, the boundary shrinks and things feel cleaner again. From that perspective, starting with modules is a positive direction: a lot of code, limited boundaries. Questions Shipping strategy: Will the Rust extension only support nogil build? If so, that might help reduce some FFI complexity. Duplication: 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? If so, a guideline to have different implementations about same feature will be great. Having separate module paths and build flags would allow experimentation, and then flipping Rust on by default once stable. It will be work like a sort of feature-level incubators. If possible, I’d love to see this code used: GitHub - RustPython/pymath (While working on it, I learned how dealing with FMA is way nicer in Rust than in C. Thanks tim-one.) 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!
ID: 277572
Author: Éric Araujo
Created at: 2025-11-18T02:29:28.275Z
Number: 58
Clean content: Hi, Dmitry: this would open the door for the possibility of shipping with Python modern Rust-based tooling for dep management, formatting and linting Can you expand on this with some specific examples? I can only interpret this as a suggestion that Python releases would include uv and ruff, and it doesn’t make much sense to me. These projects already exist, their adoption does not depend on CPython using Rust itself. And formatters and linters are third-party projects, not developed by python-dev, and chosen by developers. One thing with special status is pip, included via ensurepip, to solve the packaging boostrapping issue.
ID: 277579
Author: Emma Smith
Created at: 2025-11-18T04:11:33.057Z
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.
ID: 277580
Author: Emma Smith
Created at: 2025-11-18T04:13:55.112Z
Number: 60
Clean content: Éric Araujo: monk-time: this would open the door for the possibility of shipping with Python modern Rust-based tooling for dep management, formatting and linting Can you expand on this with some specific examples? I can only interpret this as a suggestion that Python releases would include uv and ruff, and it doesn’t make much sense to me. Yeah on a re-read I think my earlier comment misinterpreted this message as discussing clippy and rustfmt (Rust tools). So I would say adding Python tooling that is written in Rust to CPython is out of scope for this proposal.
ID: 277581
Author: Raphael Gaschignard
Created at: 2025-11-18T04:22:28.658Z
Number: 61
Clean content: corona10: @emmatyping What I’m curious about is this: in the current PoC, most of the code uses unsafe blocks. I understand this isn’t Rust’s fault but rather a limitation of the CPython API. Still, how do these modules become memory-safe in the PoC, and how much less do we need to worry about memory safety compared to writing the same code in C? For example, if you could say something like “X% of the code in the base64 module becomes memory-safe,” that would be a helpful metric to highlight. To expand on this point, I see Rust as a potential usability gain here, much more than the security aspect. I think the argument to use Rust for CPython here would be much stronger if we could see standard_b64encode implemented in a way that takes advantage of Rust’s RAII to reduce the book-keeping we have to do in the C code right now. Without a “Rust API” here for writing these extensions, this becomes purely a security argument (that I find fairly unconvincing at some level). If standard_b64encode was returning a Result and we were able to use ? and all this other stuff with a wrapper that did “the right thing” that would be, at least to me, much more interesting EDIT: though a point against this being easy might be the memory allocation story here… though the error allocation failure paths are about allocation failures in the Python arena, not sure if that means we really have no stack left over. Still think it’s worth proving the point that this has ergonomics improvements, because that feels like a pretty big deal all things considered!
ID: 277583
Author: Emma Smith
Created at: 2025-11-18T04:40:03.220Z
Number: 62
Clean content: Raphael Gaschignard: I think the argument to use Rust for CPython here would be much stronger if we could see standard_b64encode implemented in a way that takes advantage of Rust’s RAII to reduce the book-keeping we have to do in the C code right now. Without a “Rust API” here for writing these extensions, this becomes purely a security argument (that I find fairly unconvincing at some level). If standard_b64encode was returning a Result and we were able to use ? and all this other stuff with a wrapper that did “the right thing” that would be, at least to me, much more interesting One example of reducing mental bookkeeping is the BorrowedBuffer abstraction in the implementation cpython/Modules/_base64/src/lib.rs at c9deee600d60509c5da6ef538a9b530f7ba12e05 · emmatyping/cpython · GitHub . As mentioned previously, the current example is pretty bare-bones as it is a proof of concept. There is a large room for improvement in ergonomics. But even with raw FFI bindings, it’s possible to have a safe, idiomatic Rust core of an extension module then expose that via unsafe wrappers. And I think even that will improve the safety and utility of writing extensions in CPython.
ID: 277590
Author: Raphael Gaschignard
Created at: 2025-11-18T04:56:49.874Z
Number: 63
Clean content: Yeah I think the BorrowedBuffer is a good example of helping a bit with its Drop . I guess this would be more convincing to me (random person who has little stake in this beyond poking in CPython internals from time to time but wants to see some idea of this succeed!) if we go a bit further in the barebones interpretation to prove some idea of improved ergonomics, focused entirely on this encode implementation, which includes just enough bookkeeping futzing that would be nice to not see anymore: let result = unsafe {
        PyBytes_FromStringAndSize(ptr::null(), output_len as Py_ssize_t)
    };
    if result.is_null() {
        return ptr::null_mut();
    } instead being something like: let Ok(result) = PyBytes::from_string_and_size(ptr::null(), output_len as Py_ssize_t) else { return ptr::null_mut() } ; Or even, if there’s some way to make PyResult -y thing that could collapse the common CPython errors nicely (maybe not a possible thing!): let result = PyBytes::uninit_from_size(output_len)? Just like BorrowedBuffer , it feels like there could be some single-field wrapper structs, and smart constructors that could operate in a “Rust API”-y level to work off of results Similarly in: let dest_ptr = unsafe { PyBytes_AsString(result) };
if dest_ptr.is_null() {
    unsafe {
        Py_DecRef(result);
    }
    return ptr::null_mut();
} I would have expected we could have some Rust-y wrapper on references that would give us that Py_DecRef call for free just through RAII. And maybe I’m too optimistic of Rust’s compiler toolchain, but if the wrapper was a single field struct, my impression is we would be able to get that for free. The thing I would assume is that within the extension module we could go full Rust API goodness, and it’s only really at the entry and exit points that one would need to go back to acknowledging CPython’s realities a bit more. Anyways yeah, I’m very curious what the ‘pie in the sky most of the APIs used in the encoding example have a nice API’ version of the encode port looks like, because jumping from C to Rust could make the maintenance barrier seem way lower. We don’t have to port everything, just enough and enough smoke and mirrors to say “this is what it looks like in practice for this one method”. Because right now beyond the platform support tradeoffs etc, the PoC example is also presenting as generally more code, not less. In my mind’s eye we wouldn’t even have a tradeoff here, and the code would be simpler.
ID: 277593
Author: Emma Smith
Created at: 2025-11-18T05:05:28.705Z
Number: 64
Clean content: Interactions between Python objects and borrows is rather complicated. I don’t think this thread is a great place to go over detailed API design discussion as that isn’t the goal of the PEP, but I’d be happy to chat in another forum like the Python Discord or via DM. I will say a pie-in-the-sky API will look somewhat like an implementation using PyO3 . I can write up such an implementation and share that if people think it would informative.
ID: 277594
Author: Dan
Created at: 2025-11-18T05:09:12.306Z
Number: 65
Clean content: but eventually will become a required dependency of CPython What does this mean for projects that embed CPython inside their C++ projects? Boost::python or pybind11?
ID: 277596
Author: Emma Smith
Created at: 2025-11-18T05:18:14.327Z
Number: 66
Clean content: You would need Rust to build any Rust extension modules you want in your embedded Python. I believe most embedding links to libpython so that would already be built and wouldn’t require Rust.
ID: 277597
Author: Dan
Created at: 2025-11-18T05:26:57.004Z
Number: 67
Clean content: Emma Smith: You would need Rust to build any Rust extension modules you Thank you, I know nothing of Rust, I see the word ‘dependency’ and I immediately get scared. Python and all the 3rd party modules must load into the host application’s process. In my case, I’m running Python inside AutoCAD for windows. If this is optional, or something that’s not going load some sort of runtime, or something that could cause issues, then great
ID: 277598
Author: Dmitry
Created at: 2025-11-18T05:40:40.383Z
Number: 68
Clean content: Éric Araujo: Can you expand on this with some specific examples? I can only interpret this as a suggestion that Python releases would include uv and ruff, and it doesn’t make much sense to me. We do already ship with pip and pymanager, and there’s no denying that Rust/Go have created an expectation for modern languages to include quality standard dev tooling. And it is equally apparent that the best Python tooling for the next decade will be written in Rust [1] . So I don’t see a future where Python also ships with such tools as outside the realm of possibility [2] . So I don’t see why not. This is clearly out of scope for this proposal, which is why I framed it only as a future possibility – one that would require its own difficult discussion and the platform/build support this PEP addresses. So I won’t pursue this further here. regardless of if it’s still Astral tools like uv and ruff (or ty when it reaches stable) or something else like pyrefly ↩︎ I do believe replacing pip with uv might just be the most widely applauded move Python can make ↩︎
ID: 277601
Author: Jeong, YunWon
Created at: 2025-11-18T07:32:25.879Z
Number: 69
Clean content: To achieve good ergonomics, we’ll need not only cpython-sys but also another crate built on top of it that provides proper Rust abstractions. (Following naming conventions, it would be called cpython , but that name is already taken.) Right now, the PEP only covers cpython-sys , but if we expect Rust ergonomics by this PEP, I think some consideration of this additional crate should also be included.
ID: 277602
Author: Michał Górny
Created at: 2025-11-18T07:39:20.436Z
Number: 70
Clean content: This would be unfortunate for Gentoo. We’re currently one of the few Linux distributions that aim to provide a reasonable working experience for people with older, weaker or more niche hardware that is not supported by Rust; and given that we’re largely talking about volunteers with no corporate backing, there is practically zero chance of ever porting LLVM and Rust to the relevant platforms, let alone providing long-term maintenance needed for keeping them working in projects with such a high rate of code churn. I do realize that these platforms are not “supported” by CPython right now. Nevertheless, even though there historically were efforts to block building on them, they currently work and require comparatively little maintenance effort to keep them working. Admittedly, the wider Python ecosystem with its Rust adoption puts quite a strain on us and the user experience worsens every few months, we still manage to provide a working setup. The moment CPython starts requiring Rust, this will no longer be possible. Of course, we will still be able to provide older versions of CPython for a few years, at least until some major package starts requiring the newer Python version. That said, I do realize that we’re basically obsolete and it’s just a matter of time until some projects pulls the switch and force us to tell our users “sorry, we are no longer able to provide a working system for you”. I don’t expect to change anything here. Just wanted to share the other perspective.
ID: 277603
Author: Stephan Sokolow
Created at: 2025-11-18T08:27:56.307Z
Number: 71
Clean content: I hope nobody will mind if my first post as a complete newcomer to the forum (though very far from one with Python or Rust) is letting my designed-to-win-trivia-games brain provide some context, clarifications, etc. for various things across the thread as a whole. Also, sorry for splitting this across multiple posts but, even after pessimizing all my citations to “Search for …” annotations, it was still claiming I had more than two links in it. (If this posts, then I guess it meant two reply-to-post embeds.) Pre-PEP: Rust for CPython Core Development I’m not a core dev nor expert in the internals of CPython, but I wanted to chime in to resonate with the question from @MegaIng , pointing out though that it looks to me (as a Python user) that the community in general is more “approachable” in comparison to what happened during the integration of some Rust in the Linux kernel. 
Out of curiosity, what would this mean for both PyO3 and RustPython ? Have you reached out to the mantainers of the latter for feedback on how to approach this possibilit… Finally, if I recall rust applications tend to be a bit “bloated” in binary size, although there are some tricks that can be done at compile time to reduce this - what do these tricks imply on performance I have no idea. The answer depends on how long ago you remember that from. Rust’s history has been a tale of improving defaults on this front and I don’t know where you draw the line on “bloated”. For example, prior to Rust 1.28 (Search for “Announcing Rust 1.28” site:blog.rust-lang.org ), some platforms embedded a copy of jemalloc but it now defaults to the system allocator. Rust still statically links its standard library, which is distributed as a precompiled “release + debug symbols” artifact to be shared between release and debug profiles and, for much of its life, there was no integrated support for stripping the resulting binaries. According to the Profiles (Search for “The Cargo Book” “Profiles” site:doc.rust-lang.org ) section of The Cargo Book, strip = "none" is still the default setting for the release profile. If I do a simple cargo new and then cargo build --release the resulting “Hello, World!”, the binary is 463K, which drops to 354K if the debuginfo is stripped. That remaining size includes things like a statically linked copy of libunwind which wouldn’t be needed if using abort on panic as mentioned by Emma Smith… but I’m not up to speed on how much of that will get stripped out without rebuilding the standard library to ensure it isn’t depending on them. (See my later mention of how the Rust team are currently prioritizing stabilizing -Zbuild-std as part of letting “remove kernelspace Rust’s dependency on nightly features” shape much of the 2025 roadmap.) Beyond that, one potentially relevant piece of tooling is dragonfire ( amyspark/dragonfire on the FreeDesktop Gitlab) as introduced in Linking and shrinking Rust static libraries: a tale of fire. (Search for “Linking and shrinking Rust static libraries: a tale of fire” site:centricular.com ) (Which is concerned with deduplicating the standard library when building Rust-based plugins as static libraries.) Pre-PEP: Rust for CPython Core Development Doesn’t “C“ in the name of “CPython“ means “C programming language”? If so, shouldn’t the project be eventually renamed when a significant part of it is (re)written in Rust? 
/joke, but who knows Just declare “CPython” to be referring to the stable ABI exposed rather than the implementation language. After all, the abi_stable crate for dynamically linking higher-level Rust constructs does it by marshalling through the C ABI.
ID: 277604
Author: Stephan Sokolow
Created at: 2025-11-18T08:28:34.839Z
Number: 72
Clean content: Pre-PEP: Rust for CPython Core Development I have long liked the idea of doing something like this, and as someone who always introduces memory leaks and segfaults and such any time he writes any kind of C extension code, I welcome the idea of more modern zero-cost abstractions for that [1] . 
However, one cost I think that has not been mentioned here is the effect that this could have on build times. In my experience, compile times for Rust (and C++) are much slower than for C. On my 2019 Thinkpad T480, from a fresh clone of CPython, I ca… I guess the question is a dual one: can we write Rust in a way that it will not cause build times to explode and if we cannot, is the plan to keep the scope of Rust in CPython to a level where building is still very accessible? I don’t see why it needs to be slow. As laid out in The Rust compiler isn’t slow; we are. (Search for "The Rust compiler isn't slow; we are." site:blog.kodewerx.org ), rustc is already faster than compiling C++ with GCC and the reason builds are slow has more to do with how much the Rust ecosystem enjoys the creature comforts of macros and monomorphized generics. Pre-PEP: Rust for CPython Core Development In my experience incremental Rust builds are also very fast–the initial setup (including downloading and building all the dependencies) can be slow, but it’s able to do fast incremental builds just fine. 
Also, there’s a big difference between debug and release mode–building in debug mode is way faster. I would be surprised if this impacted iteration time unless you’re trying to rebuild the world every time. …and they’re working on making it faster still. Aside from “Relink, Don’t Rebuild”, as mentioned by Jubilee, there are two bottlenecks which disproportionately affect incremental rebuilds right now: First, while there’s parallelism between crates and in the LLVM backend, the rustc frontend is single-threaded. Work is in progress and testable in nightly (Search for “Faster compilation with the parallel front-end in nightly” site:blog.rust-lang.org ) for making the frontend multithreaded. They’re also working on rustc_codegen_cranelift ( rust-lang/rustc_codegen_cranelift on GitHub) which is a non-LLVM backend for rustc which makes more Go-like trade-offs for compile-time vs. runtime performance and is intended to eventually become the default for the debug profile. Second, linking. They’ve been rolling out LLD as a faster default linker on a platform-by-platform basis and it came to Linux in 1.90. (Search for “Announcing Rust 1.90.0” site:blog.rust-lang.org ) Beyond that, mold is faster still (it’s what I use on my system) and wild ( davidlattimore/wild on GitHub), yet faster, is being developed with an eye toward becoming default for debug builds alongside rustc_codegen_cranelift. (i.e. Doesn’t cover all the needs of a fully general-purpose linker, but does make debug builds for the majority of them very quick.)
ID: 277605
Author: Stephan Sokolow
Created at: 2025-11-18T08:29:38.639Z
Number: 73
Clean content: I claim that one of the major reasons for this failure is that cargo is almost unique among build systems in providing absolutely no structured mechanisms for: (1) communicating with other package build scripts in the same dependency graph (2) communicating with the downstream user who invokes cargo (such as a distro packager, or a github actions pipeline) This is a known problem that’s been discussed more or less since v1.0 came out in 2015 but more pressing issues keep jumping ahead of it in the queue. (eg. The 2025H2 roadmap is prioritizing stabilizing an MVP of -Zbuild-std so that embedded and low-level projects like Rust for Linux (i.e. kernelspace Rust) don’t need to use either a nightly compiler or the secret switch to use API-unstable features on stable channel.) If you want to search up existing discussions, what was done to incorporate Rust builds into Bazel got mentioned a lot. Pre-PEP: Rust for CPython Core Development Nothing in particular. 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. It should be noted that, if I understand “GCC Testing Efforts” site:gnu.org correctly, GCC’s support for all platforms would count as “Tier 3, at varying degrees of stubbornness” by Rust testing standards since I don’t see any mention of any of the “Current efforts” entries being integrated to the same “CI on every push and will block merging into main if it fails” degree. Rust’s approach to Tiers 1 and 2 leans in the direction of “We don’t trust our testing to be sufficient for Continuous Deployment, but we’ll do it as diligently as if we were pushing directly to stable channel”. EDIT: …and, apparently, there’s also a limit on number of posts for new users so I can’t get it all in without breaking the rule about no substantial edits. I’ll drop an in-reply-to-embed and add a GitHub Gist containing the source for the entire thing as it was before I started making any changes to try to crunch it in. In total, the posts being replied to, as represented in the auto-updating Discourse permalink URLs, are 4, 9/12, 15, 16, 18, 19, 30, and 38, and a few I forgot to grab URLs for while blockquoting, and the bits which don’t fit include an answer to the concern about Trusting Trust attacks, a clarification about “Rust guarantees that code outside an unsafe {} block is safe”, a mention of #[repr(transparent)] , and a few other little things.
ID: 277606
Author: GalaxySnail
Created at: 2025-11-18T08:30:27.638Z
Number: 74
Clean content: If python cannot be built without rust in the future, I believe the difficulties this would bring to bootstrapping are being underestimated. Python is such a widely used programming language that many projects have started to use python during the build stage. For example, glibc and gcc require python to build ( https://github.com/fosslinux/live-bootstrap/commit/69fdc27d64ec56ad59b83b99aab0747c9d9f81ed ). If python depends on rust, it would mean that all projects using the meson build system would also need rust to bootstrap (I know muon can be a replacement, but muon isn’t 100% compatible with meson). The live-bootstrap project has already completed the bootstrap of python, and it currently requires a total of 11 builds to obtain CPython 3.11.1, including regenerating all generated code ( https://github.com/fosslinux/live-bootstrap/blob/master/parts.rst#159python-201 ). And even when using mrustc to build rust 1.74.0, it still requires 18 builds to obtain rust 1.91, especially since the time required to build rustc is much longer than CPython. Moreover, rust releases a new version every 6 weeks, so this number will grow quickly. Compilation time is also an issue. Although incremental builds in debug mode may be fast, this is not always possible, for example when doing distribution packaging, when using git bisect , or when debugging bugs that only reproduce in release mode. Currently, a full CPython build is still relatively fast, and I agree that it would be acceptable if the full build time were up to 2x slower. Regarding the previously mentioned issue with os.fork , I am not sure whether using fork in a single-threaded process is safe. If using fork in a single-threaded process would still break rust’s safety guarantees, then os.fork and multiprocessing.get_context("fork") would become completely unusable, and that would break many third-party libraries that depend on it. On the other hand, rust occasionally introduces breaking changes outside of editions, for example https://github.com/rust-lang/rust/issues/127343 , and the potential impact of such risks on CPython should be considered carefully.
ID: 277609
Author: David Hewitt
Created at: 2025-11-18T09:21:31.306Z
Number: 75
Clean content: Eclips4: Can we integrate MIRI into our workflow? I spoke to some of the Miri maintainers about running PyO3 through Miri a while ago, I believe back then there were limitations due to all the C FFI being opaque to Miri. I vaguely recall the conversation concluded those limitations could be lifted, would just need some work. I’m not aware of anything to make me think that work has been done yet. 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). At the moment PyO3 has two abstractions, the low level FFI which this pre-PEP proposes generating with bindgen and the high-level abstractions which are totally safe. I’ve wondered about a third level which sits between the two; it would still use unsafe extern “C” ABI and call the C symbols directly, but the types for input & output could encode the possible states, e.g. BorrowedPtr(*mut PyObject) or even Option<NonNull<PyObject>> to force null checking. As long as these are layout identical with the actual C type passed through the FFI, it would just improve type safety without actually introducing any overheads or much “high level” API. There is a lot of scope to experiment here. Gankra: In practical specific terms, it’s often reported that Rust often makes implicit ownership/lifetime constraints in C APIs explicit and easier to work with. The Rust bindings to C functions can include lifetimes that enforce these contracts (and yes a lot of C APIs map onto lifetimes and ownership well). I agree fully with this - in particular a huge win is that you don’t need to remember to call Py_Clear / Py_DecRef / Py_XDecRef on every error pathway, RAII abstractions can just solve this for you. Your point here also speaks to what I was musing about in the point above. barry: The former is surely a smaller number, and my guess is that even fewer are comfortable in Rust today . Absolutely true that while many core devs may not currently be comfortable in Rust, there is a lot of anectotal evidence that after an initial learning curve many people find Rust relatively easy to feel productive and comfortable in. (Google’s experience with Android strongly supports this, for example.) CEXT-Dan: Thank you, I know nothing of Rust, I see the word ‘dependency’ and I immediately get scared. Python and all the 3rd party modules must load into the host application’s process. In my case, I’m running Python inside AutoCAD for windows. If this is optional, or something that’s not going load some sort of runtime, or something that could cause issues, then great Many Python packages are already built in Rust, they’re precompiled and uploaded to PyPI as binary distributions which users can use without any awareness they’re built in Rust. CPython using Rust as an implementation detail would be no different for anyone not building from source. mgorny: Admittedly, the wider Python ecosystem with its Rust adoption puts quite a strain on us and the user experience worsens every few months, we still manage to provide a working setup. @mgorny the Python ecosystem user experience is important to me and I’m aware there have been pains as tooling has adopted to Rust support. Gentoo particularly runs into these pains due to so much from-source building and extensive hardware support. I’m sure I’m not aware of every possible configuration, please always do feel free to ping me / direct me at things and I will do my best to help. I build PyO3 / integrate Python & Rust to empower more people to write software, not to alienate.
ID: 277610
Author: Stephan Sokolow
Created at: 2025-11-18T09:33:34.110Z
Number: 76
Clean content: On the other hand, rust occasionally introduces breaking changes outside of editions, for example I don’t think it’s fair to call Rust out for that specifically, given that it’s not a Rust-specific problem and that, as demonstrated in places like graydon2’s retrobootstrapping rust for some reason , my prior mention of which got spilled into the GitHub Gist because “New users can’t…”, "Modern clang and gcc won’t compile the LLVM used back then (C++ has changed too much – and I tried several CXXFLAGS=-std=c++NN variants!) Modern gcc won’t even compile the gcc used back then (apparently C as well!) Modern ocaml won’t compile rustboot (ditto) While I don’t have numbers, given that Rust’s regression suite became a bottleneck on development before Microsoft started donating Azure time, and that they have Crater (a bot for testing proposed changes against slices of the public crate registry up to and including “all of it”), I suspect Rust introduces breaking changes less than C and C++ do.
ID: 277613
Author: Sergey "Shnatsel" Davidoff
Created at: 2025-11-18T10:26:36.392Z
Number: 77
Clean content: Rosuav: open questions such as the impact of a potential Ken Thompson style compiler hack . Will CPython lose trust by becoming dependent on a single specific compiler that might be subject to such a hack? There is an alternative Rust compiler implementation in C++, mrustc , that implements just enough Rust to compile the official Rust the compiler without relying on it in any capacity. The official Rust compiler bootstrapped both ways (original chain and mrustc) produce identical binaries, which is sufficient to prove the absence of the Ken Thompson hack.
ID: 277614
Author: Sam James
Created at: 2025-11-18T10:42:34.330Z
Number: 78
Clean content: It should be noted that, if I understand “GCC Testing Efforts” site:gnu.org correctly, GCC’s support for all platforms would count as “Tier 3, at varying degrees of stubbornness” by Rust testing standards since I don’t see any mention of any of the “Current efforts” entries being integrated to the same “CI on every push and will block merging into main if it fails” degree. Rust’s approach to Tiers 1 and 2 leans in the direction of “We don’t trust our testing to be sufficient for Continuous Deployment, but we’ll do it as diligently as if we were pushing directly to stable channel”. I don’t really want to derail this thread into a discussion on models of testing, but a similar discussion was had the other week on lobste.rs . I don’t think it’s a accurate summary to say Rust’s ‘testing standards’ just mean ‘Tier 3’ for GCC.
ID: 277616
Author: Stephan Sokolow
Created at: 2025-11-18T10:45:00.902Z
Number: 79
Clean content: Thank you. Is there any chance that clarification could be added to GCC Testing Efforts - GNU Project since that’s what shows up in search results?
ID: 277617
Author: Sam James
Created at: 2025-11-18T10:45:32.617Z
Number: 80
Clean content: In the thread, I did promise to work on improving documentation, so yes, it will be done. EDIT: Filed PR122742 for that.
ID: 277620
Author: Marc-André Lemburg
Created at: 2025-11-18T11:07:55.689Z
Number: 81
Clean content: I’m a firm -1 on proceeding in this direction. The reference implementation CPython is called CPython for a reason, after all, By adding additional requirements, we make CPython less portable, maintenance a lot harder and complicate adoption in spaces where you need to recompile the whole package to other platforms such as WASM. Besides, there already is a GitHub - RustPython/RustPython: A Python Interpreter written in Rust effort. I’m sure they’d love to get more support. If you want to use Rust for writing optional extensions, that’s perfectly fine, but please upload them to PyPI instead of requiring Rust in the CPython core.
ID: 277621
Author: Jacopo Abramo
Created at: 2025-11-18T11:19:03.755Z
Number: 82
Clean content: Members of both the RustPython community and PyO3 already expressed their interest in this approach, as already pointed out from the previous replies on this thread.
ID: 277622
Author: Antoine Pitrou
Created at: 2025-11-18T11:24:33.496Z
Number: 83
Clean content: David Hewitt: I spoke to some of the Miri maintainers about running PyO3 through Miri a while ago, I believe back then there were limitations due to all the C FFI being opaque to Miri. I vaguely recall the conversation concluded those limitations could be lifted, would just need some work. I’m not aware of anything to make me think that work has been done yet. And conversely, would a ASAN/UBSAN build of CPython be able to see/instrument the Rust parts? Otherwise, not seeing the full program execution could impair the ability of the instrumentation to find bugs at runtime.
ID: 277623
Author: Josh Cannon
Created at: 2025-11-18T11:49:37.806Z
Number: 84
Clean content: barry: One of the soft consequences I’m especially interested in is whether this attracts more or fewer core developers contributing to the Rust bits than the C bits. Anecdata: I don’t plan on writing any (more) C code, so outside of all the non-coding ways that exist, I don’t see myself ever meaningfully becoming a contributor to CPython (‘s core). On the other hand, I can’t write enough Rust to scratch the itch. And I don’t think I’m particularly unique or special here
ID: 277625
Author: David Hewitt
Created at: 2025-11-18T12:00:14.672Z
Number: 85
Clean content: pitrou: And conversely, would a ASAN/UBSAN build of CPython be able to see/instrument the Rust parts? ASAN can definitely work with the caveat that this is a nightly Rust feature at present - sanitizer - The Rust Unstable Book UBSAN - I’m less sure, I suspect that the C parts would be instrumented, the Rust parts would not, I would think this would not impact getting meaningful value from the sanitizer.
ID: 277628
Author: Kivooeo
Created at: 2025-11-18T12:30:12.238Z
Number: 86
Clean content: Hi from the Rust Compiler Team! As someone who programmed in Python for several years previously, I’m really excited to see this! I haven’t read the entire thread, but I have a minor concern that I previously raised personally with Kirill and wanted to bring here as well. After reading the PEP, one question remains regarding the specific version of Rust that will be used in Python. While Rust maintains excellent stability for the vast majority of users, large foundational projects like CPython often benefit from more conservative versioning strategies. Following approaches used by other large projects, would it make sense to pin specific Rust versions and update deliberately. Additionally, the policy around nightly features isn’t entirely clear. These often contain some quality-of-life improvements that might assist development. Within the Rust compiler itself, we regularly rely on many nightly features, so their treatment remains an open question from the PEP. These are the main points that I feel still need clarification after reading the proposal. Thank you for your tremendous work on integrating Rust into Python – it will be very exciting to watch this progress!
ID: 277633
Author: Michał Górny
Created at: 2025-11-18T12:55:29.578Z
Number: 87
Clean content: davidhewitt: mgorny: Admittedly, the wider Python ecosystem with its Rust adoption puts quite a strain on us and the user experience worsens every few months, we still manage to provide a working setup. @mgorny the Python ecosystem user experience is important to me and I’m aware there have been pains as tooling has adopted to Rust support. Gentoo particularly runs into these pains due to so much from-source building and extensive hardware support. I’m sure I’m not aware of every possible configuration, please always do feel free to ping me / direct me at things and I will do my best to help. I build PyO3 / integrate Python & Rust to empower more people to write software, not to alienate. Thank you, and I am grateful for your help whenever we run into specific problems with Rust. Unfortunately, here the problem is Rust itself — for platforms it doesn’t support, all we can do is either drop the package from that platform (which generally means also dropping all the packages that require it) or remove the Rust dependency somehow. For the latter, it often means disabling tests (which is far from optimal, but there’s at least some hope that testing on other platforms will suffice for pure Python packages), and lately replacing uv-build with a pure Python build system (say, when cachecontrol started using it, given it’s required by pip and poetry ).
ID: 277635
Author: Dima Tisnek
Created at: 2025-11-18T13:08:30.429Z
Number: 88
Clean content: Thank you Emma and Kirill for taking this on. The kudos you deserve is beyond what can be expressed in words. While I love reading the virtues of rust extolled… there are perhaps some areas that pre-pep should address that got glossed over. Rust’s approach to memory safety in multithreaded programs is very different from Python’s. In fact, I don’t think it can be used out of the box. Please make a plan or a PoC and show otherwise. Or set out an educated set of guards rails. Looking at the sample module, this stood out to me: #[inline]
fn encoded_output_len(input_len: usize) -> Option<usize> {
    input_len
        .checked_add(2)
        .map(|n| n / 3)
        .and_then(|blocks| blocks.checked_mul(4))
} This is just rust for the sake of rust. A safe C equivalent would be two lines long. The moral is that not all valid rust code belongs to CPython, just like PEP-7, there needs to be a spec about what rust features and idioms to use and what not to.
ID: 277637
Author: David Hewitt
Created at: 2025-11-18T13:24:41.824Z
Number: 89
Clean content: dimaqq: Rust’s approach to memory safety in multithreaded programs is very different from Python’s. From subinterpreters, yes I agree there are differences. From freethreaded Python, it has so far felt very similar to me (atomic datatypes, locks etc). dimaqq: This is just rust for the sake of rust. A safe C equivalent would be two lines long. This code could be written in a one liner if really wanted, I wouldn’t pick at LOC as a relevant metric. Some Rust code is more verbose than C because it encourages checking, some Rust code is less verbose because it (e.g.) handles RAII for you. #[inline]
fn encoded_output_len(input_len: usize) -> Option<usize> {
    (input_len.checked_add(2)? / 3).checked_mul(4)
}
ID: 277638
Author: David Hewitt
Created at: 2025-11-18T13:26:50.201Z
Number: 90
Clean content: dimaqq: The moral is that not all valid rust code belongs to CPython, just like PEP-7, there needs to be a spec about what rust features and idioms to use and what not to. clippy and rustfmt are fantastic tools (configurable) that enable a common standard of Rust to be used widely across the ecosystem with specific tailoring possible. I would think these will be great (possibly sufficient) starting points.
ID: 277643
Author: Alex Gaynor
Created at: 2025-11-18T13:56:47.268Z
Number: 91
Clean content: dimaqq: A safe C equivalent would be two lines long. FWIW, I’ve tried pretty hard, but I can’t find a way to write a (readable) 2-line version of this function in C that retains the overflow checking. (And any C version I do either relies on a magic sentinel like -1 for a return value or an out param, which is obviously more challenging for the caller). I think this is a good example of a dynamic with Rust: it definitely forces you to front load a lot of work. It’s more annoying for building POCs and playing with ideas. The trade-off is you get way less debugging and vulnerabilities on the back side.
ID: 277644
Author: Sergey Fedorov
Created at: 2025-11-18T14:00:13.923Z
Number: 92
Clean content: This is very disappointing to see rust being pushed into Python itself. That will break Python for all platforms where rust is broken, which will hit users badly, since a lot of apps rely on Python. (And will be a regression as compared to C implementation generally.) Using it optionally, like Ruby does, is fine. I honestly hope it does not become obligatory.
ID: 277645
Author: Jakub Beránek
Created at: 2025-11-18T14:07:34.735Z
Number: 93
Clean content: To provide some numbers on Rust’s build performance: today, I can build the whole Rust compiler (600 kLOC) plus its ~200 dependencies (a couple more hundred kLOC) on my Zen3 16 core (8C+8HT) laptop in ~50s from scratch, in release mode with optimizations, with incremental rebuilds taking 5-20s (depending on how deep I modify something in the dependency tree). While that is still slower than rebuilding CPython, especially in incremental, I don’t think that the initiative mentioned in this PEP would run into Rust build time performance issues soon, unless you somehow manage to write (or depend on) hundreds thousands of Rust code very quickly.
ID: 277648
Author: ShalokShalom
Created at: 2025-11-18T15:19:04.037Z
Number: 94
Clean content: Rust’s memory safety guarantees have been formally proven by the RustBelt project for code that does not use “unsafe” . There are CVE’s in safe Rust
ID: 277654
Author: Antoine Pitrou
Created at: 2025-11-18T15:42:51.203Z
Number: 95
Clean content: Well, there are CVEs in pure Python too, that doesn’t mean that Python and C are equivalent when it comes to avoiding security vulnerabilities.
ID: 277656
Author: Bill Janssen
Created at: 2025-11-18T16:41:48.408Z
Number: 96
Clean content: I think this is a great idea! So much so I finally signed onto the Discourse server to endorse it. Will follow developments with much interest.
ID: 277660
Author: Michael H
Created at: 2025-11-18T16:54:46.173Z
Number: 97
Clean content: No, but it does undercut the idea that the memory safety guarantees have been “formally proven” when there are longstanding known direct counterexamples. For what it’s worth, Miri does catch that issue.
ID: 277661
Author: Dustin Spicuzza
Created at: 2025-11-18T17:01:24.594Z
Number: 98
Clean content: Emma Smith: How should we manage dependencies? By default cargo will download dependencies which aren’t already cached locally when cargo build is invoked, but perhaps we should vendor these? Cargo has built-in support for vendoring code. We could also cargo fetch to download dependencies at any other part of the build process (such as when running configure). Currently, it is trivial to build python on a computer that isn’t connected to the internet. IMO this must continue to be the case, it’s really important to many users in restricted environments.
ID: 277663
Author: Michael H
Created at: 2025-11-18T17:20:53.414Z
Number: 99
Clean content: I have too many concerns about the use of Python in various bootstrapping to be in favor of this currently. I agree with the overall goal of increasing memory safety and making it easier to write code people can be confident in by default, and I like Rust for this, but I don’t see this as the right move without more supporting pieces that just aren’t there yet when considering how Python is used in the world. It seems more advantageous to focus on which modules have both C and Python implementations that would highly benefit from the guarantees afforded. This also seems to have cleaner boundaries on a technical level, and doesn’t force people to evaluate Rust adoption as an all-or-nothing roadmap to be committed to before it is proven to work within CPython’s core development, and before seeing actual impact of even that smaller transition. It’s also worth pointing out that there are options other than rust which have stronger formal guarantees than C (some more than Rust), and which don’t require a Rust toolchain. Python is already using GitHub - hacl-star/hacl-star: HACL*, a formally verified cryptographic library written in F* for various cryptography functions, and getting more from doing so than had a Rust implementation been chosen: The code for all of these algorithms is formally verified using the F* verification framework for memory safety, functional correctness, and secret independence (resistance to some types of timing side-channels). While Rust is certainly more popular than a purpose-chosen subset of F* [1] , it serves as a point that it is possible to get the level of additional compiler-enforced safety that’s desired without compromising on the existing portability of CPython. As CPython doesn’t support these unsupported triples either, Rust stabilizing user-provided JSON targets brings it to effective parity: “You’re on your own, but the build tools required have a stable way of doing it.” I also want to be crystal clear, I don’t think it’s even remotely feasible to say “Rust has to support all target triples that have ever used or ever will use python.” There’s a limited amount of maintainer bandwidth in every project, and some hardware just isn’t being developed for by the core teams. It’s niche. A probably less important issue, but one that I think hasn’t been mentioned directly [2] , is that rust and rust-analyzer both use significantly more memory than existing tooling for C. I don’t think it’s an amount likely to be a significant contribution barrier, and don’t personally count this against the proposal, but would like to make sure all known impacts are considered. Low* ↩︎ Compile times were mentioned, but there’s workflows that avoid the brunt of this. ↩︎
ID: 277666
Author: Norman Lorrain
Created at: 2025-11-18T17:37:57.979Z
Number: 100
Clean content: Given that Rust isn’t standardised like C and C++ (ISO/IEC 9899, ISO/IEC 14882), isn’t this premature?
ID: 277669
Author: Alex Gaynor
Created at: 2025-11-18T17:53:01.349Z
Number: 101
Clean content: Python is also not standardized, and yet I don’t think any of us believe it follows that it’s premature to use it . Can you expand a bit more on why you think standardization should play into this?
ID: 277671
Author: Kirill Podoprigora
Created at: 2025-11-18T17:56:54.370Z
Number: 102
Clean content: That’s a good question! But I guess the real question here is: what problem does standardization actually solve? Android and Linux seem to be doing just fine with Rust, even though it doesn’t have a formal standard. Here’s an article from Mara (a member of the Rust Leadership Council) that discusses this topic: https://blog.m-ou.se/rust-standard/ .
ID: 277672
Author: Stephan Sokolow
Created at: 2025-11-18T18:08:43.682Z
Number: 103
Clean content: The distinction is that those are implemented using I-unsound -tagged bugs in the compiler (and no comparably advanced optimizing compiler is completely free of them) and the underlying formal proof is for “if all compiler bugs are fixed”… similar to how you shouldn’t fault a language for the underlying DRAM being susceptible to Rowhammer . I don’t have the URLs on hand, but, if I remember correctly, GCC and LLVM have equivalent tags in their bug trackers. In this context, the reason some of those bugs are long-lived is twofold: The developers have determined that they’re very difficult to encounter accidentally. Neither the rustc devs nor the LLVM devs nor the GCC devs nor any developers of optimizing compilers are willing to take on “this transformation is a security boundary, fit for processing mailcious inputs”-level responsibility.
ID: 277673
Author: Stephan Sokolow
Created at: 2025-11-18T18:15:27.107Z
Number: 104
Clean content: Rust has multiple mechanisms for building without access to Crates.io , depending on the specific circumstances. For example: cargo fetch and cargo build --offline can be used to separate the downloading and building while otherwise using Cargo the same way. cargo vendor can be used to vendor the dependencies without losing the information that something like cargo-audit would need. The Overriding Dependencies section of the Cargo Book covers things like overriding the Crates.io repository URL to locally point a package at a different source. While I haven’t kept up on the state of the art, it’s possible to run a local mirror of Crates.io more broadly using tools like Panamax . I think that covers all the major tiers of the problem.
ID: 277674
Author: Norman Lorrain
Created at: 2025-11-18T18:16:54.221Z
Number: 105
Clean content: I think in terms of a tech stack, as you go further down you want to be increasingly conservative and prevent any breaking changes.  This has been the success of Windows, which for all it’s faults is quite backward compatible.  I can take code from 30 years ago and it will run.  Similarly for the Web.  I can look at archived pages from decades ago and it will display. Python is the foundation for many projects and businesses.  I trust that code I write today will run in 1 or 2 or 5 years.  10 years, less trust. Lessons learned from 2to3 transition. In turn, C is the foundation of Python.  I trust that any changes to C will not impact Python and my investment of time, etc. won’t be at risk. The core issue is trust. There is “currency” in trust.  Python has a healthy bank account of trust, and I fear it will be at risk.
ID: 277675
Author: Stephan Sokolow
Created at: 2025-11-18T18:22:07.057Z
Number: 106
Clean content: Generally speaking, standardization tends to come into play for one of two purposes: Re-unifying disparate implementations of a language (C, C++, ECMAScript, etc.) Making a proprietary product look more appealing to enterprise or government decision-makers (Java, .NET, Office Open XML, etc.) Given that Rust’s regression suite and v1.0 stability promise already pin the language down more thoroughly than C or C++ and that gccrs plans to follow rustc as the source of truth, I’m not sure a standard would have much benefit here. (Seriously. Look into how much about C is left implementation-defined. We generally greatly overestimate what the spec actually calls for. That’s one reason you tend to see big projects picking one or maybe two compilers per platform and coding against those. For example, the Linux kernel is written in GNU C and the ability to compile it using llvm-clang was a little bit about retiring use of features the kernel devs had decided were mistakes and overwhelmingly about teaching llvm-clang to support GNU C. …it also has its own non-standard memory model that only works because GCC is careful not to break it.)
ID: 277677
Author: Norman Lorrain
Created at: 2025-11-18T18:27:18.924Z
Number: 107
Clean content: See my other answer, regarding trust.  Having a standard provides some measure of trust in a technology that is a foundation of a project. I know nothing about Android, but I read that Ubuntu had a problematic release with their porting of uutils/coreutils to Rust in 25.10.  Those tools are a foundation to a Linux system. This undermines trust in Ubuntu. I’d hate for the same to happen to Python.
ID: 277678
Author: James Webber
Created at: 2025-11-18T18:28:16.038Z
Number: 108
Clean content: I don’t know that there is a level of standardization or certification that can satisfy every vague concern.
ID: 277679
Author: Stephan Sokolow
Created at: 2025-11-18T18:31:08.268Z
Number: 109
Clean content: Personally, my trust in Python was broken as soon as I saw lines in the standard library docs saying things like Deprecated since version 3.6, removed in version 3.12. (Specifically the latter half.) It’s one of the things that made me feel relieved that I’d decided to work on a Rust rewrite for any code that doesn’t need memory-safe QWidget bindings, Django’s ecosystem, or Django ORM/Alembic draft migration autogeneration in order to minimize the “It works. Don’t **** with it” vs. “Burned myself out again trying to reinvent a stronger type system in my test suite” factor.
ID: 277682
Author: Tin Tvrtković
Created at: 2025-11-18T18:38:17.862Z
Number: 110
Clean content: Love this effort, a strong +1 from me. I’ve been historically wary of bigger CPython contributions because I don’t know C, and don’t particularly want to know it. Rust is a completely different matter. A lot of the introduction here is aimed at Rust as a replacement for the C parts of CPython. But I think Rust could be a huge win for optimizing Python parts of CPython. “Rewrite module X in C” usually means a significant effort, both up front and on-going, maintenance-wise. Rewriting in Rust could be a completely different story, if we do this right.
ID: 277683
Author: Norman Lorrain
Created at: 2025-11-18T18:40:45.970Z
Number: 111
Clean content: Maybe a standardisation to the effect that code from The Rust book, 1st edition, or 2nd edition, still work with the latest Rust. (Perhaps it does).
ID: 277684
Author: Stephan Sokolow
Created at: 2025-11-18T18:44:18.998Z
Number: 112
Clean content: It should. See Stability as a Deliverable for a description of Rust’s “v1.0 Stability Promise”. Basically, so long as you’re not depending on a compiler bug or security hole, the only thing which should be allowed to break vN code in any later vN+M version of the Rust compiler is the occasional change to how type inference works in edge cases. …also, I almost forgot to mention this: Ubuntu’s troubles with uutils are, in my opinion and in the opinion of others, self-inflicted. The uutils devs are quite up-front that they haven’t yet achieved their goal of passing all the tests in the GNU Coreutils test suite, so Ubuntu trying to use them is similar to all the distros that made a mess by ignoring KDE’s announcement that 4.0 was meant to be a developer preview.
ID: 277685
Author: William Woodruff
Created at: 2025-11-18T18:47:05.212Z
Number: 113
Clean content: Norman Lorrain: The core issue is trust. There is “currency” in trust. Python has a healthy bank account of trust, and I fear it will be at risk. How should the Python community quantify this trust, given that your original metric (standardization) doesn’t apply to Python itself? Conversely: do you moderate your trust in CPython based on the presence of unstandardized, compiler-specific extensions? The last time I checked, there were a nontrivial number of GCC extensions and attributes in the codebase (other compilers go to great efforts to be compatible with these, but they’re not standard).
ID: 277686
Author: Sam James
Created at: 2025-11-18T18:47:33.294Z
Number: 114
Clean content: Basically, so long as you’re not depending on a compiler bug or security hole, the only thing which should be allowed to break vN code in any later vN+M version of the Rust compiler is the occasional change to how type inference works in edge cases. Use of unstable features in crates is more common than I’d like it to be still, and the promise does not apply to that. CPython should avoid any use of them. Rust for Linux currently relies on some such features, though they’re making an effort to stabilise the ones they’re relying on and not introduce more.
ID: 277687
Author: Sam James
Created at: 2025-11-18T18:49:54.681Z
Number: 115
Clean content: cargo fetch and cargo build --offline can be used to separate the downloading and building while otherwise using Cargo the same way. That option would require some work besides git clone which may not be desirable. It does bring up the general question of whether CPython would want to aggressively use crates (which can bring licence questions too) or not. CPython currently has a pretty small set of external dependencies.
ID: 277688
Author: Stephan Sokolow
Created at: 2025-11-18T18:55:21.893Z
Number: 116
Clean content: thesamesam: Use of unstable features in crates is more common than I’d like it to be still, and the promise does not apply to that. CPython should avoid any use of them. Fair point. I haven’t used nightly for anything but the occasional nightly-only tool run (eg. Miri) in at least five years, but then I don’t do kernelspace stuff and using Rust for microcontroller hobby programming is still on my TODO list. My experience has been that there isn’t much call for nightly for cargo build -ing userspace projects anymore. thesamesam: That option would require some work besides git clone which may not be desirable. It does bring up the general question of whether CPython would want to aggressively use crates (which can bring licence questions too) or not. CPython currently has a pretty small set of external dependencies. I’d imagine cargo vendor would probably be a better fit for that. Beyond that, cargo-deny is good for enforcing policy on dependencies (licenses, security advisories, etc.) and cargo-supply-chain helps to automate the process of inspecting who you’re trusting, independent of how many pieces they decided to split their project into.
ID: 277689
Author: Emma Smith
Created at: 2025-11-18T19:07:35.013Z
Number: 117
Clean content: I wanted to start by thanking everyone for their feedback on the proposal so far, and say that we look forward to continued discussion. After reviewing the discussion so far, we’ve decided to re-focus the (pre-)PEP to only propose the introduction of optional Rust extension modules to CPython. We hope that with experiences gained from introducing Rust for extension modules, Rust can eventually be used for working on the required modules and the interpreter core itself in the future. However, we will leave that to a future PEP when we know more and will not be proposing that as part of the current in-discussion PEP. This should address issues with bootstrapping, language portability, and churn. We’ve also been noting lots of other feedback we’ve received, but I wanted to call this one out in particular as it has been the source of a large portion of the discussion.
ID: 277691
Author: Chris Angelico
Created at: 2025-11-18T19:59:46.895Z
Number: 118
Clean content: William Woodruff: Conversely: do you moderate your trust in CPython based on the presence of unstandardized, compiler-specific extensions? The last time I checked, there were a nontrivial number of GCC extensions and attributes in the codebase (other compilers go to great efforts to be compatible with these, but they’re not standard). I would, but the moderation in question is relatively slight. There are two levels of trust: “Do I believe this isn’t malicious?” and “Do I believe that this is able to do what it promises?”. The compiler-specific extensions don’t significantly affect the first one (any sort of malicious implication has to be incredibly convoluted, like “the CPython devs are trying to force people to use GCC because they are trying to boost Richard Stallman’s fame and try to get him into the Guinness Book of Records” - or something equally ridiculous), though they do have an impact on the second (“in the event of a problem, do we have true options here?”). So, yes, it does impact trust, but not all THAT much. Non-standard/compiler-specific features, to me, recall the days of IE-specific features in web sites, which had the much-less-convoluted justification “Microsoft wants everyone to use IE so they have to buy Windows”. But the trust impact depends on how viable the threat is.
ID: 277692
Author: Elchanan Haas
Created at: 2025-11-18T20:20:28.247Z
Number: 119
Clean content: emmatyping: When should Rust be allowed in non-optional parts of CPython? I think the timeline you are laying out here is a bit too certain. I would instead propose a timeline based on the adaption of Rust within Python. In Python 3.15, ./configure will start emitting warnings if Rust is not available in the environment. Optional extension modules may start using Rust. (Same as PEP proposal) Once the Rust has enough usage within Python extensions a PEP will be created with a timeline of making Rust mandatory.
ID: 277694
Author: Emma Smith
Created at: 2025-11-18T20:32:56.369Z
Number: 120
Clean content: This is no longer the current plan, please see Pre-PEP: Rust for CPython - #117 by emmatyping I don’t think we should emit a warning now that these items will be entirely optional and we don’t have a plan for making Rust required. When that is proposed in a PEP, the timeline for emitting warnings and requiring Rust will be decided there.
ID: 277695
Author: Norman Lorrain
Created at: 2025-11-18T20:34:48.478Z
Number: 121
Clean content: I would quantify it in terms of the timeline a codebase will still run.  1,2,5,10 years. Yes, I moderate it.  I’ve been burned by changes, and I guess this is why a foundational change like moving to Rust causes concern.  Why not defer this to Python 4?
ID: 277696
Author: James Webber
Created at: 2025-11-18T20:44:25.949Z
Number: 122
Clean content: Because there’s no plan to ever have a Python 4.
ID: 277697
Author: William Woodruff
Created at: 2025-11-18T21:03:38.697Z
Number: 123
Clean content: Norman Lorrain: I would quantify it in terms of the timeline a codebase will still run. 1,2,5,10 years. Yes, I moderate it. I’ve been burned by changes, and I guess this is why a foundational change like moving to Rust causes concern. Why not defer this to Python 4? I don’t think CPython makes a hard and fast guarantee that your code will run unmodified in 1, 2, 5, or 10 years. But even if it did: the presence of Rust inside the runtime doesn’t seem material to that property, or at least is no more material to it than everything that happens on each minor release of Python 3 anyways.
ID: 277698
Author: James Webber
Created at: 2025-11-18T21:24:37.466Z
Number: 124
Clean content: Emma Smith: This is no longer the current plan, please see Pre-PEP: Rust for CPython - #117 by emmatyping Given that this thread reached 100+ posts in a day (!), you might want to edit the OP to make this clear. This thread is getting some broader coverage and I expect more people will be jumping in without reading the whole thing.
ID: 277713
Author: Zachary Harrold
Created at: 2025-11-18T23:28:51.925Z
Number: 125
Clean content: barry: I would go further and predict that this will never happen, and claim that it shouldn’t be a goal of the Rust-in-Python project. There are 10**oodles of person-years invested in the CPython core interpreter, and I just don’t see how that will ever be cost effective to rewrite, even as a Ship of Theseus . I mean, there’s already +12,777,745/-9,190,109 total changes in a project with (currently) 2,791,005 lines of text (git diffs include non-code so this count does too). Arguably, cpython has been rewritten at least 4 times now.
ID: 277714
Author: Emma Smith
Created at: 2025-11-18T23:29:22.571Z
Number: 126
Clean content: Good idea, I updated the OP to mention and link to the updates to the timeline section, but left the original text for posterity.
ID: 277721
Author: Filipe Laíns
Created at: 2025-11-19T02:32:15.541Z
Number: 127
Clean content: Hi, thank you for being willing to take on this project! The proposal overall seems great, with the proposal scope and bootstrapping story being the only potentially major issues I see. I am only gonna comment on that, as other folks are already addressing remaining concerns. This discussion is already big as-is, and I have no doubt it will still grow much larger Proposal scope Unless I am misinterpreting it, the proposal foreword seems to imply that this is a phased proposal that will eventually add Rust as a required build dependency of CPython, but the presented PEP only covers making it an optional build dependency. This proposal declares Rust will at some point will stop being optional. While I understand the motivation, I feel like deciding this right now is too early. I don’t think the PEP provides strong enough supporting evidence to outweigh the potential implications of such a major change. The downstream impact is still pretty up in the air, as is the impact on development, etc., while the potential benefit of introducing Rust into the core code-base is still very unclear. When I say the benefit of using Rust in core is unclear, I am not questioning Rust’s benefit over C. It’s the quantity of opportunities where it would make sense to use it that is unclear. I strongly believe we should not be rewriting existing code in Rust without a specific reason, and that’s what I think is unclear at this point. Even the PEP is unsure of the timeline for promoting Rust to a hard build dependency, probably because of this. I think this proposal would be much easier to drive forward if it were split into two phases, each with its own PEP. Introducing Rust as an optional build dependency Promoting Rust to a hard build dependency This way, 1) would allow us to gather feedback from the development team, downstreams, etc., giving us a much better picture of the impact of 2), enabling us to make a better argument and design a more concrete plan. With this in mind, here are my suggestions for the PEP text: Add an “Abstract“ section explaining that the PEP is a first step into the adoption of Rust in the CPython codebase, introducing it in an optional capacity, allowing us to experiment, gather developer feedback, and better assess the technical implications of using Rust in CPython. Add a “Goals“ section Explicitly state that rewriting existing code in Rust without further motivation is a non-goal Define a couple of goals, like the following Evaluate how well the development team engages with Rust inside the codebase Evaluate how well the CPython architecture couples with Rust Evaluate the impact of first-party Rust APIs on downstream users (eg. PyO3) Gather feedback from downstream users regarding the bootstrapping implications Gather feedback from downstream users of platforms where Rust is not supported Add a “Future“ section explaining that, contingent on the impact of this PEP, we plan to promote Rust to a hard build dependency as a next step Remove “Keep Rust Always-Optional“ from “Rejected Ideas” TLDR I don’t feel the PEP provides enough justification to make Rust a hard build dependency, and I think that’s something that would be difficult to provide at this point. As such, I feel like this proposal would be better served by splitting into two phases/PEP — starting with adding Rust as an optional build dependency, and then promoting it into a hard build dependency. Bootstrapping I personally don’t think any of the given solutions are good enough at the moment, so it is very important to explore other options. IMO, even if no better solutions are found, the PEP authors should show they have exhausted all other sensible possibilities. That said, I may be mistaken, but it’s my understanding that Python should only be needed to build LLVM for rustc . Perhaps it would be worth exploring the possibility of using the Cranelift backend instead, which AFAICT doesn’t need Python. It may also be worthwhile to engage with the mrustc project, as they may have better insights on other possible approaches. Another thing that I thought it would be pertinent to point out. If we were to introduce Python to the bootstrapping dependency tree (via Rust), that would greatly weaken the argument against moving CPython’s build system to Meson (discussion in What do you want to see in tomorrow’s CPython build system? ).
ID: 277722
Author: James Webber
Created at: 2025-11-19T02:34:58.859Z
Number: 128
Clean content: Filipe Laíns: I don’t feel the PEP provides enough justification to make Rust a hard build dependency, and I think that’s something that would be difficult to provide at this point. Good news, this was agreed upon somewhere in the next 100ish posts of the thread.
ID: 277725
Author: Stephan Sokolow
Created at: 2025-11-19T04:03:18.487Z
Number: 129
Clean content: I claim that one of the major reasons for this failure is that cargo is almost unique among build systems in providing absolutely no structured mechanisms for: (1) communicating with other package build scripts in the same dependency graph (2) communicating with the downstream user who invokes cargo (such as a distro packager, or a github actions pipeline) An update on work in this direction: The GSoC results page details progress on Prototype Cargo Plumbing Commands . Not what you asked for, but evidence of how this sort of thing is on the radar.
ID: 277731
Author: Alyssa Coghlan
Created at: 2025-11-19T06:59:55.463Z
Number: 130
Clean content: I’ll chime in with a +1 on the idea of allowing Rust extension modules, -1 (at least for now) for the core interpreter and compiler (which is already the direction the descoped PEP has moved in). For the core interpreter (at least the part which needs to be built in order for CPython to freeze its own frozen standard library modules), I think the bootstrapping and long tail platform support concerns are significant enough to at least postpone consideration of the possibility, and potentially even enough to block it forever. For extension modules manipulating untrusted input data, I see huge potential value in having access to Rust as a fast low overhead statically typed language with rich data structures and implicitly thread local data access. (For a concrete example of that from nearly 10 years ago, here’s a Sentry post about migrating their JavaScript source map processing from Python to Rust , and the benefits of not incurring the per-instance overhead of creating full Python objects). There are some cases where platform compatibility may still be a concern, but extension modules will have more options for handling that than the core interpreter does.
ID: 277732
Author: Dima Tisnek
Created at: 2025-11-19T07:09:23.108Z
Number: 131
Clean content: alex_Gaynor: dimaqq: A safe C equivalent would be two lines long. FWIW, I’ve tried pretty hard, but I can’t find a way to write a (readable) 2-line version of this function in C that retains the overflow checking. My take: if (len > PRECOMPUTED_CONST) return -1;
return (len + 2) / 3 * 4; My point was exactly about the fact that crustaceans worry about overflow checking, borrow safety, traits, etc., and write verbose code that is beautiful, while pragmatic folk reduce the problem, put safety limits leaving the implementation very short. After all, what’s the point of encoding a string that’s larger than a fraction of the total address space? The Rust overflow checker is only effective at ~3/4 RAM, at which point the argument and result cannot fit into RAM at the same time. Fancy Rust safety is totally appropriate for user-defined or external input (e.g. networking code, cryptography or json.dumps argument where some inner dict-like object may have a custom dunder method that does some “caching” but ends up modifying sibling elements in flight or creates cycles), while simple concepts should in my opinion remain simple, so that the code remains maintainable, ideally also by contributors who are not Rust experts. Which is why I’m calling for the equivalent of PEP-7 for Rust use in CPython. ShalokShalom: Rust’s memory safety guarantees have been formally proven by the RustBelt project for code that does not use “unsafe” . There are CVE’s in safe Rust I’d go even further and decry “proven safe” as smoke and mirrors. Remember the BAN logic proof for the Needham–Schroeder protocol? To recap, every proof is against a certain fixed set of assumptions. Meanwhile what happens in practice is that software is reused in ways unpredictable a priori. RustBelt has proven something about Rust, but not about Rust use in CPython, or Rust use in 3rd party Python extensions and certainly not about Rust used within CPython when an arbitrary user program is run by the interpreter, with arbitrary additional extension, for arbitrary goals and with arbitrary thread model. Here my call is to move most of Rust exultations into the footnotes, and focus on tangible direct benefits instead: safer refactoring / faster reviews, broader contributor pool / potentially more approachable to new contributors who grew up with safe/typed languages, specific CPython core bug classes (not generic C bugs), cleaner (more self-documented) internal APIs, safer norms for 3rd party extensions, possibly safer/faster backport story, potentially better tooling, possibly CPython guts (e.g. regexp) shared as crates for other uses…
ID: 277734
Author: Emma Smith
Created at: 2025-11-19T07:32:31.612Z
Number: 132
Clean content: Dima Tisnek: Which is why I’m calling for the equivalent of PEP-7 for Rust use in CPython. This is definitely something I hope to work on with folks. We will need a standard style for Rust in CPython, but I also think that might depend as we adopt Rust and expand the current proof of concept. Regardless it probably should be it’s own PEP, in my mind drafted and published after this one is approved. Dima Tisnek: RustBelt has proven something about Rust, but not about Rust use in CPython That’s certainly true, but in projects that have adopted Rust for a while, we see significant decreases in memory safety bugs. Here’s an excerpt from a blog about Rust adoption in Android: We adopted Rust for its security and are seeing a 1000x reduction in memory safety vulnerability density compared to Android’s C and C++ code . But the biggest surprise was Rust’s impact on software delivery. With Rust changes having a 4x lower rollback rate and spending 25% less time in code review Our historical data for C and C++ shows a density of closer to 1,000 memory safety vulnerabilities per MLOC. Our Rust code is currently tracking at a density orders of magnitude lower: a more than 1000x reduction. From Google Online Security Blog: Rust in Android: move fast and fix things I agree with you that it is important to highlight that Rust can increase developer velocity as well as provide memory safety. I think this is something we will highlight more in the PEP draft and is something a few people have mentioned. Here’s another excerpt from the above blog related to that: For medium and large changes, the rollback rate of Rust changes in Android is ~4x lower than C++. Rust changes currently spend about 25% less time in code review compared to C++. These are definitely things we will be focusing on more in the PEP text itself.
ID: 277740
Author: Stephan Sokolow
Created at: 2025-11-19T08:50:24.905Z
Number: 133
Clean content: dimaqq: To recap, every proof is against a certain fixed set of assumptions. Meanwhile what happens in practice is that software is reused in ways unpredictable a priori. RustBelt has proven something about Rust, but not about Rust use in CPython, or Rust use in 3rd party Python extensions and certainly not about Rust used within CPython when an arbitrary user program is run by the interpreter, with arbitrary additional extension, for arbitrary goals and with arbitrary thread model. While I agree that focus should be on other benefits (eg. I spent a decade in /r/rust/ and people coming from C++ loved the tooling most), I think it goes too far to call “proven safe” smoke and mirrors. That stance generalizes far too easily to things like “It’s a waste of time to make Python memory safe because import ctypes exists”, which makes it far too easy for people to dismiss… especially when the whole point of things like the safe/unsafe split and the way parts of Rust have been formally verified is to draw boxes around bits of code and say “assuming no external factor, such as bad RAM or abuse of unsafe violates the invariants, this code’s behaviour will meet expectations”.
ID: 277741
Author: Ricardo Robles
Created at: 2025-11-19T08:53:05.681Z
Number: 134
Clean content: I’m not a Rust expert; I only have work experience with C/C++ and Python. What advantages would Rust have over other languages ​​like Go? I’m just asking to understand Rust’s advantages and to make sure it’s for a real reason and not just to “Rustify” everything.
ID: 277742
Author: Stephan Sokolow
Created at: 2025-11-19T08:55:50.106Z
Number: 135
Clean content: Go depends on having a garbage collector and garbage collectors are solitary creatures, which makes it unsuitable for writing extensions or rewriting components of a C or C++ codebase. (That’s one reason Jython and IronPython exist, instead of integrating CPython with the JVM and CLR. They live within the JVM or CLR’s existing GC instead of competing with it.) Rust is noteworthy because it’s the only language to gain significant traction in this niche previously held almost exclusively by C and C++. EDIT: To elaborate on that, Rust enables compile-time guarantees that C and C++ are incapable of without relying on a heavy VM to do it. That’s what makes it essentially unique. (Though other languages like D and Ada are starting to copy Rust’s innovations.)
ID: 277746
Author: Miraculixx
Created at: 2025-11-19T09:06:42.019Z
Number: 136
Clean content: Not a core dev, yet experienced in large scale sw development including changing of core tech. Spoiler alert: these efforts usually fail. I always recommend to answer three key questions before embarking on changing foundational pieces of the stack: Is the new stack introduced for its coolness instead of solving an actual problem? Will the new stack introduce new problems that the old stack does not have? Does the investment in time and effort to introduce the new stack compete with more worthwile work that delivers value to users? If the answer to any of these questions is yes, and the change is pressed on anyway, the outcome will eventually land in one of two states: Efforts will stall and the resulting two-stack system is more complex than ever before, effectively meaning the change will be consuming ever more resources to no good cause. The complexities introduced by the new stack have a far higher blast radius than previously anticipated, triggering a complete rewrite, eventually reaching feature parity with no added value. In short, I recommend to avoid the introduction of Rust as an alternative to C in CPython(!).
ID: 277749
Author: Kirill Podoprigora
Created at: 2025-11-19T09:34:33.025Z
Number: 137
Clean content: Miraculixx: Not a core dev, yet experienced in large scale sw development including changing of core tech. Spoiler alert: these efforts usually fail. We’ve received a lot of messages from people who want to help, and even members of the Rust core team are willing to support us. As we mentioned earlier, there are two strong examples of Rust adoption done right: Rust for Linux and Rust for Android. Here’s the blog post from the Android team: Google Online Security Blog: Rust in Android: move fast and fix things We’re fully committed to putting a lot of effort into this initiative, and to making sure we don’t fail Miraculixx: Is the new stack introduced for its coolness instead of solving an actual problem? We’re addressing a real problem: CPython like many other projects written in C or C++ suffers from memory-safety vulnerabilities. Rust can drastically reduce the number of these vulnerabilities. From the Android blog post: We adopted Rust for its security and are seeing a 1000x reduction in memory safety vulnerability density compared to Android’s C and C++ code . Miraculixx: Will the new stack introduce new problems that the old stack does not have? I’m pretty sure this project will encounter at least one challenge: CPython contributors who don’t know Rust will need to dedicate some time if they want to contribute to the Rust parts. Other challenges will only become clear as we move forward, and that’s where members of the Rust core team may be able to help us. As I understand it, they supported the Rust for Linux project as well. Miraculixx: Does the investment in time and effort to introduce the new stack compete with more worthwile work that delivers value to users? Sorry, but I’m reading that part of your message as if this were about business. CPython is an open-source project, and most of us volunteer our time for free. Because we’re volunteers, we’re free to choose whichever problems we want to work on. So, we chose this problem and here’s the solution we believe in: Rust . Miraculixx: Efforts will stall and the resulting two-stack system is more complex than ever before, effectively meaning the change will be consuming ever more resources to no good cause. The complexities introduced by the new stack have a far higher blast radius than previously anticipated, triggering a complete rewrite, eventually reaching feature parity with no added value. I’d like to quote Android blog again: But the biggest surprise was Rust’s impact on software delivery. With Rust changes having a 4x lower rollback rate and spending 25% less time in code review , the safer path is now also the faster one.
ID: 277752
Author: Miraculixx
Created at: 2025-11-19T09:52:56.490Z
Number: 138
Clean content: Eclips4: We’re fully committed to putting a lot of effort into this initiative, and to making sure we don’t fail Said every team ever. I don’t doubt that. Just for reference, can you point to some of the memory saftey issues that would have been avoided if CPython were using Rust?
ID: 277758
Author: Zander
Created at: 2025-11-19T10:08:08.246Z
Number: 139
Clean content: It is undeniable that Rust offers superior safety over C and can effectively prevent many errors that would otherwise occur. However, introducing Rust into CPython may inevitably lead to some divergence within the community, with some developers in favor and others potentially having reservations. Additionally, this would require developers to be proficient in C, Rust to effectively address related issues. More importantly, as the proportion of Rust code in the project gradually increases, there may be growing calls within the community for a full transition of CPython to Rust. This could further intensify disagreements among core developers, somewhat reminiscent of certain situations the Linux community has experienced in the past. If all proceeds smoothly, we might eventually achieve a RustPython that remains compatible with the C ABI. That said, RustPython already exists today, though it still lags behind CPython in terms of features and ecosystem. Wouldn’t steadily improving it be a more feasible path forward? This approach may prove more manageable than integrating Rust directly into CPython. If there is a clear advantage to introducing Rust into CPython, it may lie in the ability to gradually migrate the official Python implementation from C to Rust while preserving existing functionality and compatibility. If the current path is maintained, CPython will continue to be implemented in C, and even if RustPython develops remarkably, replacing the official implementation would present significant challenges—since doing so would likely require the current maintenance team to undergo a major transition.
ID: 277762
Author: Kirill Podoprigora
Created at: 2025-11-19T10:12:51.385Z
Number: 140
Clean content: gh-133767: Fix use-after-free in the unicode-escape decoder with an error handler by serhiy-storchaka · Pull Request #129648 · python/cpython · GitHub and many other UAFs
ID: 277764
Author: Stephan Sokolow
Created at: 2025-11-19T10:53:11.705Z
Number: 141
Clean content: Zander-1024: If all proceeds smoothly, we might eventually achieve a RustPython that remains compatible with the C ABI. That said, RustPython already exists today, though it still lags behind CPython in terms of features and ecosystem. Wouldn’t steadily improving it be a more feasible path forward? This approach may prove more manageable than integrating Rust directly into CPython. Whenever I see arguments like this, I get the impression that the people making such an argument forget what “volunteer” means. If they’re not getting paid to work on Python, then it’s entirely possible that it’s not “Rust vs. C”, but “Rust vs. wear out and stop contributing”. I know that situation is why I’m rewriting my Python projects in Rust. Even without memory safety on the line and even with strict-mode MyPy, the constant vigilance of a dynamic language with ubiquitous NULL/None/nil and exceptions introducing hidden return paths all over the place wears on me.
ID: 277785
Author: Jacopo Abramo
Created at: 2025-11-19T15:17:01.954Z
Number: 142
Clean content: I don’t want to bring fuel to the fire as I’m just observing the decision making process, but the timing of the situation was just too funny for me. Apparently in September Cloudflare migrated some internal library to Rust … … and after investigation, the recent November outage was effectively caused by some code that wasn’t appropriately managing memory in this new library. But at any rate the pre-PEP has already been discussed exhaustively, it was just my sense of humour that found this hilarious in the context of this discussion where lots of points about integrating Rust were about memory safety.
ID: 277790
Author: Paul Moore
Created at: 2025-11-19T15:43:03.986Z
Number: 143
Clean content: Stephan Sokolow: If they’re not getting paid to work on Python, then it’s entirely possible that it’s not “Rust vs. C”, but “Rust vs. wear out and stop contributing”. This is a good point that doesn’t seem to be getting enough attention. I can’t speak for any of the core devs that routinely work on the C parts of the codebase, but I can say that personally, there were a number of improvements that I would have loved to make to the old py launcher, which I gave up on because I couldn’t face the manual memory management, and pointer manipulation, involved in string processing in C. If the launcher had been written in Rust [1] , then I could have used Rust’s standard string type, and as a result I would have been motivated to work on those improvements. So yes, a significant benefit of using Rust, even just for isolated parts of the Python stdlib, is that it could dramatically reduce the risk of developer burnout. Of course, we have to take care not to have the transition process burn people out as well, but I’m in favour of doing extra work to manage a short-term transition exercise in order to set up a better long term foundation. An entirely reasonable possibility, it was self contained, and its build process is isolated from the core build. ↩︎
ID: 277807
Author: Roman Vlasenko
Created at: 2025-11-19T17:20:57.412Z
Number: 144
Clean content: jacopoabramo: it was just my sense of humour that found this hilarious in the context of this discussion where lots of points about integrating Rust were about memory safety. I’d say that this is misleading. The Cloudflare’s outage actually has nothing to do with the memory safety guarantees of Rust or with inappropriately managing memory in general.
ID: 277808
Author: Davide Rizzo
Created at: 2025-11-19T17:27:57.550Z
Number: 145
Clean content: I’m a huge fan of this proposal. Thanks everyone for the effort. I volunteer to support in the endeavor in any way needed. The technical details can be discussed in due time, but one thing I’d love is for CPython API to define things around ownership and thread safety more formally. Right now this is delegated to documentation, but both C users and foreign language binding implementers (e.g. Rust and C++) would benefit if they could verify that a certain reference is meant to be owned or borrowed and so on. I understand there are challenges on both the technical and social aspect. I wish for both the aspects to be cared for seriously (and I renew my availability for help). It’s not the first time that adoption of Rust in a big project brings up some strong [1] resistance. I feel that there is space to adequately understand needs and worries; and to empower the people who have some stake in this change to impact the process. For example, some people brought up a worry that Rust is chosen because it’s a trendy toy rather than an actual solution. It’s good to spend time identifying why this is considered a problem, why it is a worry, and what can be done to address it. In part this is being done now (thanks to everyone who took time to answer) by reassuring that there is technical merit and proper research into the solution. But maybe this is not the whole argument and people would like to hear something closer to their worry. In other contexts I’ve seen a resistance to Rust adoption as a sort of threat to job stability (growing as a proficient C programmer takes a huge investment and attention to a number of issues, and something like Rust seems to promise to automate away part of your skill set), and maybe that also needs to be treated with care and empathy. And, on the other side, people wanting to see Rust introduced have their needs (that might not be entirely obvious besides the technical value) and might be faced with walls and gatekeeping and, as it happened in other projects, could be discouraged or burn out when they don’t see those needs understood, or their good will acknowledged. So, please, let’s not disregard that this is a socially loaded topic, and people are already reacting in many ways. I hope that the discussion will be smooth but I will not bet on it. and, sometimes, unexpectedly violent or vicious. Fortunately nothing of that sort is visible on this thread. ↩︎
ID: 277812
Author: Stephan Sokolow
Created at: 2025-11-19T18:58:54.670Z
Number: 146
Clean content: To elaborate on “nothing to do with […] Rust”, the outage was down to: We wrote a recipient service which preallocates memory as an optimization. Since we wrote it to ingest data from one of our other services, we made the assumption the data would always be well formed and had it preallocate 3⅓ times as much space as we’re currently using. We committed a bug to the sender service which caused it to produce data bundles that blew past that 3⅓ times safety margin. It’s a logic bug. If they’d written it in C or C++ it would have been an ASSERT or SIGSEGV and, in Rust, it was doing the equivalent of dying with an uncaught AssertionError . (Basically, a violation of “Assume ‘unreachable’ never is”.)
ID: 277835
Author: Emma Smith
Created at: 2025-11-19T22:33:31.068Z
Number: 147
Clean content: Davide Rizzo: I volunteer to support in the endeavor in any way needed. Excellent! Thank you! Davide Rizzo: The technical details can be discussed in due time, but one thing I’d love is for CPython API to define things around ownership and thread safety more formally. Right now this is delegated to documentation, but both C users and foreign language binding implementers (e.g. Rust and C++) would benefit if they could verify that a certain reference is meant to be owned or borrowed and so on. I think that in Linux they have seen a number of improvements by better defining the ownership of various parts of the kernel, so this would be very nice. I think it may be a while before it is feasible, but we shall see! Davide Rizzo: So, please, let’s not disregard that this is a socially loaded topic, and people are already reacting in many ways. I hope that the discussion will be smooth but I will not bet on it. Very important to remember! Going into working on this proposal I was trying to be very cognizant that this topic can engender strong feelings. I think overall I have been pleased with how the discussions have gone so far. I think so far folks have demonstrated that they can engage on this topic in a level-headed and cordial manner. I hope that trend continues. I also hope it has been clear in my own communications that I hope to understand and care about the the views of people who may disagree with the proposal. I do not want to drive away current contributors. I will also re-iterate that if anyone would like to chat about concerns regarding the proposal not in a discussion thread, please feel free to DM me!
ID: 277845
Author: Emma Smith
Created at: 2025-11-19T23:53:39.410Z
Number: 148
Clean content: Zander: RustPython already exists today, though it still lags behind CPython in terms of features and ecosystem. Wouldn’t steadily improving it be a more feasible path forward? I don’t think so for a couple of reasons. First, RustPython are semantically different enough that I think merging the semantics would be a significant undertaking: Jeong, YunWon: RustPython isn’t something that can be considered in this PEP in short term. RustPython and CPython are not semantically compatible across many layers of their implementation. Jeong, YunWon: RustPython has its own approach to running without a GIL, but it’s not compatible with CPython’s nogil direction. Second, introducing Rust to CPython would see direct benefits to the millions of users CPython has today. Improving RustPython might see benefits to it’s current user base, but to get current CPython users to switch would need to be earned through proven compatibility over a long time period. That sounds like much more of an uphill battle with unclear benefits.
ID: 277847
Author: Brett Cannon
Created at: 2025-11-20T00:22:54.256Z
Number: 149
Clean content: Alyssa Coghlan: long tail platform support concerns FYI Git 2.52 now optionally uses Rust and it will be required in Git 3 . Zander: introducing Rust into CPython may inevitably lead to some divergence within the community Divergence how? The key people who would be affected by this are: Core developers People who build CPython from source But as has already been stated, the PEP will have Rust usage be optional, so really, the people who will be affected by the planned PEP are: Core developers And so far I have seen more +1 than -1 from core developers. Paul Moore: If the launcher had been written in Rust GitHub - brettcannon/python-launcher: Python launcher for Unix (although admittedly I’m now curious to see if Python performance is such that I can just do it in pure Python and package it up appropriately).
ID: 277849
Author: H. Vetinari
Created at: 2025-11-20T00:58:32.354Z
Number: 150
Clean content: Emma Smith: I think that in Linux they have seen a number of improvements by better defining the ownership of various parts of the kernel, so this would be very nice. This is one of the points that Greg KH [1] explicitly calls out repeatedly as a benefit of the Rust-for-Linux effort, even if Rust went away again (here’s a recent talk with a timestamped link ): By forcing the C APIs to define their semantics, the C APIs themselves often were improved. one of the most veteran Linux contributors, maintainer of LTS kernels and involved in every security issue ↩︎
ID: 277874
Author: GalaxySnail
Created at: 2025-11-20T04:51:04.783Z
Number: 151
Clean content: Brett Cannon: FYI Git 2.52 now optionally uses Rust and it will be required in Git 3 . Git 2 → Git 3 sounds like Python 3 → Python 4. Git isn’t a programming language, you only need an implementation of Git’s wire protocol to interoperate with others, don’t even need to keep the on-disk format compatible. I don’t think Git’s choice necessarily tells us what we should do for CPython. Since the authors of this pre-PEP have already decided to make Rust optional for CPython, there isn’t much more to discuss about making Rust required.
ID: 277875
Author: Stephan Sokolow
Created at: 2025-11-20T05:10:25.037Z
Number: 152
Clean content: Git 3 is bringing in support for SHA256 commit hashes, which is a protocol break. (From what I remember, Rust is used to write the part which allows seamless SHA1 → SHA256 transitioning within a repo.)
ID: 277888
Author: Da Woods
Created at: 2025-11-20T07:02:05.591Z
Number: 153
Clean content: Question related to RustPython: they look to have made good progress on compatibility but not great progress on performance so far. Is there anything to be learned from why? I.e. if it’s just lack of time and contributors then it probably isn’t very interesting to this discussion, but if they were finding some optimisations difficult in Rust it might be useful to know.
ID: 277894
Author: Jeong, YunWon
Created at: 2025-11-20T08:17:12.463Z
Number: 154
Clean content: da-woods: Question related to RustPython: they look to have made good progress on compatibility but not great progress on performance so far. Is there anything to be learned from why? 2 main reasons, which are mirror-side of each other. First, the core language part of CPython is very well optimized. RustPython adopt a few parts of them, but not able to finish major parts of them. Second, RustPython contributors (like me) didn’t have enough interests on the performance. So it happened just occasionally. So… that’s not by technical issues. Just lack of driving to the performance. If anyone interested in enhancing performance of RustPython, I will do my best support.
ID: 277898
Author: Jeong, YunWon
Created at: 2025-11-20T08:27:30.787Z
Number: 155
Clean content: emmatyping: Interactions between Python objects and borrows is rather complicated. I don’t think this thread is a great place to go over detailed API design discussion as that isn’t the goal of the PEP, but I’d be happy to chat in another forum like the Python Discord or via DM. I will say a pie-in-the-sky API will look somewhat like an implementation using PyO3 . A sample clone in RustPython; it is not PyO3 though. The technical details will differ, but once Rust for CPython gains sufficient abstraction, it will reach a similar level in terms of cognitive load. github.com/youknowone/RustPython _base64 main ← _base64 opened 08:08AM - 20 Nov 25 UTC youknowone +87 -0 ## Summary by CodeRabbit

* **New Features**
  * Base64 encoding support is now … available in the standard library. Users can encode binary data into standard Base64 format with built-in error handling and safety guarantees for large datasets. This enables reliable and efficient data transformation for applications requiring text-safe data representation and enhanced cross-platform system compatibility.

<sub>✏️ Tip: You can customize this high-level summary in your review settings.</sub>
ID: 277904
Author: Mark Shannon
Created at: 2025-11-20T09:58:39.817Z
Number: 156
Clean content: Personally, I think this makes a lot of sense for extension modules and some components, but not so much for the core of the VM (the interpreter, gc, and core objects). The safety, or lack of safety, of those components depends not so much on the language they are written in, but the design. If you feed dodgy bytecode to the interpreter it should crash, or worse. That’s how it is supposed to work. What is the proposed API for rust? The section on implementation talks about using bindgen, but what is the underlying C API that you are binding? The limited API or the warts-and-all “unlimited” API? You mention PY_OBJECT_HEAD_INIT but that just couples rust code to the deep internals of the VM. If we are introducing a new API, then it should be a good one. It should follow the design on HPy , or its successor PyNI . The linear typing of HPy handles should work very well with rust’s ownership model.
ID: 277922
Author: Steve Dower
Created at: 2025-11-20T14:53:31.669Z
Number: 157
Clean content: H. Vetinari: By forcing the C APIs to define their semantics, the C APIs themselves often were improved. Yes, I think this is the best we can look forward to if the plan to progressively replace the core runtime implementation with Rust were still on the cards (which I assume it is, just unofficially for now - it doesn’t make any sense at all to “put Rust in CPython” without that ambition, since you can already write an extension module using Rust without our permission [1] ). And we are already working to improve the semantics of our C APIs as quickly as we can without destroying our existing user base - adding Rust won’t help here (it’ll let us get away with more breakage for some people “because Rust”, but it’ll upset other people who still want minimal breakage, and on average I expect it’ll make no real difference). What the current proposal comes down to is “can we make some stdlib extension modules optional for some people”, where the answer is obviously “yes” as we already make a number of them optional for users who don’t have/support/want certain third-party libraries. So the slightly higher-level question is “are we willing to make some modules optional based on compiler choice, rather than based on access to the core functionality required by the module”. (For example, if I don’t want/have OpenSSL, then the _ssl module is obviously useless and best omitted. But if I don’t want/have Rust, why should I miss out on _base64 ?) That question is the real, practical impact that we have to decide on. Everything else is hypothetical and achievable in this way or in other ways. But if we’re not willing to have a more inconsistent stdlib across our userbase, then the overall question seems to be moot, at least until Rust can be assumed to be as available as make+GCC. I’ll also note here that the SC has previously approved putting obviously core functionality on PyPI (subinterpreters), so until we rotate through to an entirely new SC, I don’t think there’s a case for “has to be in core” other than taking advantage of our popularity (which has been earned through stability, so we shouldn’t ruin it by actively destabilising it). ↩︎
ID: 277923
Author: James Webber
Created at: 2025-11-20T15:05:11.703Z
Number: 158
Clean content: Steve Dower: (which I assume it is, just unofficially for now - it doesn’t make any sense at all to “put Rust in CPython” without that ambition, since you can already write an extension module using Rust without our permission ). While I think some view that as an end goal, a PEP to allow Rust extensions in the stdlib still stands on its own merit–there should be a formal decision whether to allow that expansion. Even if the ultimate goal was “let some optional extensions be Rust” it would still need a PEP, no?
ID: 277924
Author: Jelle Zijlstra
Created at: 2025-11-20T15:05:24.571Z
Number: 159
Clean content: I like the idea of moving CPython towards Rust, but I feel the current proposal is so conservative that it doesn’t really get us there. The idea is to allow optional extension modules to be written in Rust. That basically means either new accelerators for modules currently written in Python, or completely new stdlib modules (which are rare). They have to be optional, which means that we must also maintain a Python (or C!) version, at least for existing modules. The concrete suggestion is base64 , which is currently fully in Python. The “optional” part means that this proposal will make the stdlib more inconsistent across users. There are many ways the stdlib is already inconsistent in this way, but I feel that’s generally a bad situation that we should avoid making worse: ideally, Python should be the same for all users, and users who use base64 shouldn’t have to think about the details of their platform to know its performance characteristics. There might be another unfortunate consequence. Clearly, lots of people are very excited about getting Rust in CPython. But with this proposal, the only realistic way they can do that is by adding new accelerator modules. Those could be for modules that already have a C accelerator, but in that case we have to keep the C version too to avoid creating a regression for users without Rust. Or it could be for modules that are currently fully in Python. But I’m not sure how many such modules there are for which an accelerator really makes sense: in most cases, if we’d wanted a C accelerator, we’d have written one already. Therefore, we might end up with Rust code that is mostly replacing Python code, not C code, and that isn’t terribly high-impact. To get safety wins from using Rust, we have to stop using C. Not necessarily everywhere, definitely not everywhere immediately, but at least somewhere. So for this proposal to be accepted, I feel there must be a clear path towards making it possible to replace existing C code with Rust, even if that means making Rust required.
ID: 277926
Author: Antoine Pitrou
Created at: 2025-11-20T15:17:04.475Z
Number: 160
Clean content: Jelle Zijlstra: So for this proposal to be accepted, I feel there must be a clear path towards making it possible to replace existing C code with Rust, even if that means making Rust required. IMHO that “clear path” must be conditioned on the bootstrap issues being solved. As in: bootstrapping CPython-with-Rust should not be harder than bootstrapping CPython-without-Rust. Once that happens, them I’m fully +1 for Rust in CPython, including core parts.
ID: 277927
Author: Steve Dower
Created at: 2025-11-20T15:17:17.891Z
Number: 161
Clean content: James Webber: While I think some view that as an end goal, a PEP to allow Rust extensions in the stdlib still stands on its own merit–there should be a formal decision whether to allow that expansion. Sure, but as I said in the rest of my post, that “formal decision” is really “can we let some people be lacking certain stdlib modules”. The choice of language is fairly orthogonal, since it isn’t going to affect the design of the runtime at all - we might as well bundle up C++ extension modules in the same PEP, since a similar number of users will be unable to use those, and some extension modules would benefit. Also, there’s only a small gap between “the stdlib may not have this module for you” and “if you want this module, choose to add it”. The latter is already possible with whatever language you want to use, so with the re-scoped proposal, we’re only slightly reframing things from the latter to the former. Once we’re officially okay with “the library is (core modules) plus (optional modules) plus (whatever your distro adds) plus (whatever you’ve installed)”, [1] then “optional modules” could be anything from anywhere (which means it’s really easy to say “yes, they could use Rust”). For explicitness, the current situation is “the library is (core modules) plus (whatever your distro adds) plus (whatever you’ve installed)”. The only thing we’re adding here is “optional modules”. ↩︎
ID: 277929
Author: Antoine Pitrou
Created at: 2025-11-20T15:25:43.096Z
Number: 162
Clean content: Steve Dower: we might as well bundle up C++ extension modules in the same PEP, since a similar number of users will be unable to use those, and some extension modules would benefit. I don’t think it would be the case. Everywhere you have a C compiler, you probably have a C++ compiler too.
ID: 277930
Author: Steve Dower
Created at: 2025-11-20T15:26:41.390Z
Number: 163
Clean content: Antoine Pitrou: I don’t think it would be the case. Everywhere you have a C compiler, you probably have a C++ compiler too. I agree, but I’m trying to be generous here We already have an (optional) C++ extension module in the stdlib, but don’t tell anyone.
ID: 277931
Author: Kirill Podoprigora
Created at: 2025-11-20T15:49:56.537Z
Number: 164
Clean content: Jelle Zijlstra: The concrete suggestion is base64 , which is currently fully in Python. In fact, base64 is built on top of the binascii module, which is implemented entirely in C. So I think you’re right, we can try replacing the current binascii implementation with a Rust-based one.
ID: 277935
Author: Xie Qi
Created at: 2025-11-20T16:34:23.668Z
Number: 165
Clean content: This post is about Rust, so it will attract considerable attention from Rust fans. As a result, most of the comments are likely to be positive (since they come from Rust fans). We still need to wait and see. but eventually will become a required dependency of CPython and allowed to be used throughout the CPython code base <del> Additionally, using Rust (which relies on LLVM) means abandoning many niche platforms.  Is this really an appropriate choice? Many popular open-source projects use Python to some extent.  If CPython drops support for certain platforms, those platforms will no longer be able to run many projects that depend on Python. That would be truly unfortunate! Rust may mitigate some memory-related issues, but… are you really in such a hurry to introduce Rust into CPython? In any case, Rust should be made optional. This way, maintainers of (Python-dependent) open-source projects can choose whether to use the Rust-dependent features or not. They deserve to have a choice! Moreover, making Rust a mandatory dependency for CPython sounds like a proposal driven by Rust fans to push their own agenda. </dev> Perhaps we can wait until the maturity of the following options: C++26: hardening and contract Zig gcc-rs After that, we can conduct more comparisons before making a final decision.
ID: 277939
Author: Filipe Laíns
Created at: 2025-11-20T16:52:42.002Z
Number: 166
Clean content: Thanks for pointing that out, that’s a great point. Personally, I thought of optionally introducing Rust more as a way to better understand how it would affect the community, and how well it would fit into the CPython codebase, and developers’ workflows. I also don’t see a great value from allowing Rust in optional modules purely from a maintainer perspective, but I think it is a necessary step to decide on making Rust a hard build dependency. That said, maybe someone else does have a use-case where Rust being available for optional components would be great. If that’s the case, it would be great to let us know
ID: 277955
Author: Stephan Sokolow
Created at: 2025-11-20T19:19:22.841Z
Number: 167
Clean content: shynur: Perhaps we can wait until the maturity of the following options: C++26: hardening and contract Zig gcc-rs Bear in mind that Zig isn’t aiming to serve the same niche as Rust as far as safety/correctness goes (See How (memory) safe is zig? for comparative details on its design philosophy) and posts like these suggest a worrying attitude toward Rust-level safety/correctness within the groups responsible for steering C++. On “Safe” C++ by Isabella “Izzy” Muerte Safe C++ proposal is not being continued by Simone Bellavia Why Safety Profiles Failed by Sean Baxter I’m having trouble remembering what I bookmarked it under so I can link it, but I’d also add the paper Stroustrup put out within the last few years which, to me at least, felt like a sign that the defensiveness various loud C++ developers feel toward the idea of Rust-like guarantees goes all the way to the top. (Which would be consistent with what On “Safe” C++ lays out.) I remember it being longer than A call to action: Think seriously about “safety”; then do something sensible about it .
ID: 277960
Author: Emma Smith
Created at: 2025-11-20T19:42:38.788Z
Number: 168
Clean content: Jelle Zijlstra: I like the idea of moving CPython towards Rust, but I feel the current proposal is so conservative that it doesn’t really get us there. You’re completely correct here, the pre-PEP does not get us to Rust being ubiquitous in CPython. I think we probably didn’t do a good enough job explaining why the approach is so conservative, and should explain more on a potential path to make Rust ubiquitous, so let me expand on that. I want to start by echoing @FFY00 Filipe Laíns: Personally, I thought of optionally introducing Rust more as a way to better understand how it would affect the community, and how well it would fit into the CPython codebase, and developers’ workflows. We intentionally want to keep the initial test as conservative as possible for a few reasons. Right now, the impact of introducing Rust at all is not fully known, so we want to make sure that it is both easy to back out of the change if it is untenable, and understand what workflows would break when Rust becomes required. One thing this thread has reinforced for me is that CPython is used all over the place, often in places we the core team are not aware of. The only way we can properly evaluate the potential impact of making Rust required is to start warning users we hope to do so and hear about places it would break, and what is needed to change to make Rust required. As for using Rust outside of extension modules, I think it could be used for experimental, opt-in interpreter features such as the JIT. I want to be cautious of this though because I don’t want the JIT to be in the state where it should become the default but making Rust required is a blocker to that. As everything else, it should be considered if migrating to Rust makes sense for the JIT. I’d also like to cite an article by Google researchers : There is a temptation, when introducing a new language, to pursue an aggressive timeline to justify the investment with short-term gains. Such an approach, fixated on overly ambitious goals, or rapid, sweeping change, invariably carries elevated risks of failure and can actively disincentivize future adoption by disrupting roadmaps and competing with other business objectives. A more powerful strategy, the one that proved so effective for Android, is to treat language adoption as a long-term investment in sustainable, compounding growth that supports other business objectives instead of competing with them. This approach patiently accepts initially lower absolute numbers to provide the necessary time for the new language to establish a foothold, build momentum, and achieve critical mass. In summary, for Android they found that moving to Rust is a long-term investment, that may not see immediate payoffs, but that moving to Rust is a long term success with significant payoffs. I realize this is a hard sell. But to me it makes a lot sense because there is a lot of learning and investigation to do related to integrating Rust into CPython. We need to spend the early period where Rust is allowed conservatively to build out the experience and support infrastructure for making Rust for CPython succeed. I could see a path where we start very conservatively with base64, then introduce a Rust version of a more central standard library module like json (as an optional replacement to the C version to start with), then make Rust required. But this is a guess at a plausible path forward, and the final path needs to be informed from experience. Jelle Zijlstra: in most cases, if we’d wanted a C accelerator, we’d have written one already. I would push back against this. One of the theses of this pre-PEP is that contributors are not inclined to write complex C code because it is difficult to do, thus projects like a C accelerator are not getting written. As an example, the performance of the json module has been significantly slower than other implementations for a long time. Yet a re-write in C would be daunting. I think Rust would excel in cases like this. Another example is actually the base64 module! `base64` module: Link against SIMD library for 10x performance. · Issue #124951 · python/cpython · GitHub We could use the Rust base64-simd crate for an easier, significant improvement to performance. Jelle Zijlstra: To get safety wins from using Rust, we have to stop using C. Not necessarily everywhere, definitely not everywhere immediately, but at least somewhere. Wholeheartedly agree with this, and that’s the goal with base64. We want to start somewhere , to better inform efforts elsewhere. Starting simply and minimally seems like the best path to allowing us to get an understanding without risk. Jelle Zijlstra: So for this proposal to be accepted, I feel there must be a clear path towards making it possible to replace existing C code with Rust, even if that means making Rust required. I think on the contrary we will see the greatest benefits for memory safety from making new code in Rust. A usenix paper found that the majority of vulnerabilities are in new code, as older code is battle-tested. So while I think we should enable replacing C code with Rust code where it makes sense, for example the json module, I think we will still see plenty of wins in new code too.
ID: 277965
Author: Jelle Zijlstra
Created at: 2025-11-20T20:04:14.019Z
Number: 170
Clean content: Emma Smith: I think on the contrary we will see the greatest benefits for memory safety from making new code in Rust. A usenix paper found that the majority of vulnerabilities are in new code, as older code is battle-tested. While most vulnerabilities may be in new code, I doubt they are in new modules . If we add a feature to (say) the JIT, or the JSON module, we have to write new C code.
ID: 277966
Author: Emma Smith
Created at: 2025-11-20T20:05:32.356Z
Number: 171
Clean content: Mark Shannon: What is the proposed API for rust? The section on implementation talks about using bindgen, but what is the underlying C API that you are binding? The limited API or the warts-and-all “unlimited” API? To interact with the interpreter today, we need to interface with C APIs. Currently the proof of concept binds to the unstable Python APIs as well as internal ones. We definitely want to build safe abstractions over the raw C APIs for common use cases, and that could perhaps use an API like handles. But it has to wrap the existing APIs like HPy does for CPython, so these necessarily need to be exposed to Rust. Mark Shannon: You mention PY_OBJECT_HEAD_INIT but that just couples rust code to the deep internals of the VM. To define a module, we need to have some way of defining a PyModuleDef, unless we want to introduce a new module initialization protocol (which is a large proposal in of itself). Therefore we need a pointer to a PyModuleDef, which needs it’s first member to be PyModuleDef_HEAD_INIT which internally expands to a structure with it’s first member being PyObject_HEAD_INIT. So some of this coupling is necessary as part of the module initialization protocol. Changing this protocol could be something we look into, but seems like it’s own rabbit hole 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.
ID: 277967
Author: Emma Smith
Created at: 2025-11-20T20:15:58.826Z
Number: 172
Clean content: Jelle Zijlstra: While most vulnerabilities may be in new code, I doubt they are in new modules . If we add a feature to (say) the JIT, or the JSON module, we have to write new C code. We absolutely need to write new C code for the JIT, the JSON module, or most other parts of CPython when making changes and adding features. However I think demanding immediate results across the code base from introducing Rust is infeasible. I’m curious as to your thoughts on the rest of my comment explaining why.
ID: 277968
Author: Jelle Zijlstra
Created at: 2025-11-20T20:18:44.330Z
Number: 173
Clean content: My thoughts are that a proposal that allows Rust only for optional extension modules is likely not useful enough to justify the cost of adding a new language. It can be a first step (in fact, it’s a very reasonable first step!), but that means there must be a plan to expand beyond it just being an optional part of building CPython. And that in turn means that we need to deal with the concerns that are being raised around bootstrapping and niche platforms.
ID: 277970
Author: Paul Moore
Created at: 2025-11-20T20:51:15.069Z
Number: 174
Clean content: Jelle Zijlstra: My thoughts are that a proposal that allows Rust only for optional extension modules is likely not useful enough to justify the cost of adding a new language. There’s been a number of comments about “optional extension modules” in this discussion so far. I want to make sure we’re 100% clear on what we mean by this, as I’m concerned we could end up measuring the wrong thing otherwise. As an end user, I have literally no interest in what language a stdlib module (or a core feature) is written in. It’s irrelevant to me. However, I have a strong interest in what is available in the stdlib and core. Optional modules are an awkward compromise here - can I use the module safely, or do I need to account for the possibility that it might not be available? This is exacerbated by the fact that the packaging ecosystem has no way to express a dependency on “Python >= 3.13, with the tkinter module available” (for example). If we introduce Rust by using it for stdlib modules, and as a result make them (and anything that depends on them!) optional, then we risk getting negative feedback which will look like it’s a downside of Rust, when it’s actually a downside of optional modules. I think the intention is not to do this, but rather to use Rust to create accelerators for existing pure-Python modules. But if that is the case, can we be clearer about this, so that people don’t get the wrong impression? Assuming we are talking about accelerators, I feel that @Jelle has a point. Using Rust to get a faster JSON module [1] will be a good way of finding out what’s involved in adding Rust to the core build process, but I don’t think it will provide much useful feedback on whether Rust provides sufficient benefit to be worth taking further. Which prompts the question - what would useful feedback look like? And how do we get it? I don’t think that’s been clearly established yet. I have to say that I don’t think anyone cares about a faster base64 module… ↩︎
ID: 277972
Author: Steve Dower
Created at: 2025-11-20T21:08:04.750Z
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.
ID: 277975
Author: Emma Smith
Created at: 2025-11-20T21:34:12.705Z
Number: 176
Clean content: Regarding optional extension modules, here’s a rough timeline I could see and why each step is chosen to be so. The goals of this stage are to get the initial build system changes set up, and start getting experience interfacing with the C code from Rust. Extension modules are a limited interface to the interpreter which minimizes the work to do for interoperability. Ideally we would also start warning users that we plan to eventually make Rust a hard requirement, and if this is a hardship for their environment, to please relate that to us. Only optional extension modules are allowed. Even more of a limitation, they should only be introduced where they would replace a C extension module (this could be things like base64 or json). The latter restriction exists to ensure we are not limiting access to new features to those who have Rust available. I picked the base64 module because it was simple but should exercise enough parts of the build system and C interop code, but we could just as well choose the json module. The goals of this stage are to make progress on improving portability and bootstrapping workflows based on feedback from stage 1. If we don’t gather feedback in stage 1 we could also start doing so here. More modules may be ported here to get even more experience with the C <—> Rust interfacing and overall developer experience. The goals of this stage are to ensure that we have resolved bootstrapping issues and warn of the impending requirement on Rust. Make Rust an opt-out feature of the interpreter. This is an even stronger warning of the up-coming requirement. At this point the vast majority of users should be able to build CPython with Rust enabled and bootstrapping issues should be resolved to greatest extent possible. I would say at this point new extension modules can be in Rust. The goal of this stage is to integrate Rust into core parts of CPython. Rust is required to build CPython. Rust can now be used across the CPython code base. This is one hypothetical scenario. We’re not going to propose this as the specification in the PEP. Jelle Zijlstra: My thoughts are that a proposal that allows Rust only for optional extension modules is likely not useful enough to justify the cost of adding a new language. It can be a first step (in fact, it’s a very reasonable first step!), but that means there must be a plan to expand beyond it just being an optional part of building CPython. There is simply too much to consider to resolve the bootstrapping and portability problems to have a concrete plan now . I think like PEP 703 did, we could leave an open question with some version of the above roadmap. But I don’t think we have enough information at the moment. The only way to tell what the impact of introducing Rust to CPython is to introduce Rust to CPython. In the above plan we start very conservatively to ensure we don’t break anyone’s workflows until we’re confident we can introduce Rust to core. I wouldn’t want to set hard timelines to any of this because we don’t know now when we should move to the next step in the process. So I think like free-threading, it would be best to start with step 1, then have a follow-up PEP when we are confident we have the information we need to move to the other steps.
ID: 277976
Author: James Webber
Created at: 2025-11-20T21:38:01.881Z
Number: 177
Clean content: 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. Surely this step was accomplished years ago, with the caveat that the Rust extensions aren’t usually “drop-in” replacements for an existing stdlib module, because that’s rarely what someone wanted to write. I don’t think anyone doubts that such a thing is possible, though? So what would be the next proposal after that?
ID: 277977
Author: Steve Dower
Created at: 2025-11-20T21:45:24.104Z
Number: 178
Clean content: James Webber: Surely this step was accomplished years ago Yeah, that’s my point. James Webber: So what would be the next proposal after that? Write one, prove it’s better, propose stdlib inclusion. It doesn’t even have to be a drop-in replacement, it can be a net-new module (but then the proposal needs to justify adding the module, which might make it too complicated). This is the standing process for adding something to the stdlib, and all that’s different is it’s the first proposal that would also bring in a new language. But then we are at least debating the merits in the context of something concrete, rather than something that feels very hypothetical.
ID: 277979
Author: James Webber
Created at: 2025-11-20T21:49:09.190Z
Number: 179
Clean content: I think that this is missing the point of this proposal, though. 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 [1] ”. that is, one that accelerates existing functionality ↩︎
ID: 277981
Author: James Webber
Created at: 2025-11-20T21:52:27.814Z
Number: 180
Clean content: That said–maybe it’s still too early for a PEP, and the real Proof-of-Concept is to set-up a full build? (edit: and the existing repo might be insufficient for that purpose if it doesn’t cover enough ground)
ID: 277982
Author: Emma Smith
Created at: 2025-11-20T21:53:16.786Z
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.
ID: 277984
Author: Steve Dower
Created at: 2025-11-20T21:55:32.028Z
Number: 182
Clean content: James Webber: The point is not “we really need a faster base64 , and specifically it should be written in Rust”. Sure, and the fact that we wouldn’t take this proposal seriously should also indicate that the lesser proposal of “we really need … Rust” isn’t going to be any more persuasive. On the other hand, “our drop-in replacement for json or re is 10x faster than the stdlib, can we merge it” is a far more interesting discussion to have. Emma Smith: Great! So then once we have a prototype of the abstraction your concerns will be assuaged? Probably not But my interest would be piqued by a production-ready replacement for an existing module, or a new module that we want in the stdlib anyway and the best way to get it is to bring in a Rust implementation.
ID: 277986
Author: Da Woods
Created at: 2025-11-20T22:05:04.216Z
Number: 183
Clean content: emmatyping: To define a module, we need to have some way of defining a PyModuleDef, unless we want to introduce a new module initialization protocol (which is a large proposal in of itself). Therefore we need a pointer to a PyModuleDef, which needs it’s first member to be PyModuleDef_HEAD_INIT which internally expands to a structure with it’s first member being PyObject_HEAD_INIT. So some of this coupling is necessary as part of the module initialization protocol. I think PEP 793 would disagree with this and probably be simpler from a Rust point of view because it doesn’t involve C macros (although that wasn’t the specific intent of it). (No comment on the larger context of the discussion…. just the specific paragraph)
ID: 277987
Author: Emma Smith
Created at: 2025-11-20T22:07:59.858Z
Number: 184
Clean content: Da Woods: I think PEP 793 would disagree with this and probably be simpler from a Rust point of view because it doesn’t involve C macros Fair point, and perhaps we should adopt PEP 793. I hadn’t realized the PEP was accepted, exciting!
ID: 277994
Author: Brénainn Woodsend
Created at: 2025-11-20T22:44:42.131Z
Number: 185
Clean content: Slightly tangential but I find optional stdlib components to be a menace and would really like their proliferation to be minimised. For pre-built Python installations like those on python.org or python-build-standalone , there’s nothing optional about them – someone will need them therefore they must be included therefore everyone gets them whether they’re needed or not. For those installing from source, it’s a footgun with remediation steps so platform specific that they can rarely even be written down in any detail. For those building Python for other people, it’s both. For distro-provided Python, it’s a surprise extra system dependency that rarely follows any predictable pattern and doesn’t correlate to anything in a lockfile. I’ve spent way more time debugging tkinter installations than even monster PyPI packages like Qt.
ID: 277998
Author: Emma Smith
Created at: 2025-11-20T22:55:14.403Z
Number: 186
Clean content: Brénainn Woodsend: Slightly tangential but I find optional stdlib components to be a menace and would really like their proliferation to be minimised. I have heard from a number of people a similar sentiment. I think therefore it’d be best if a new Rust module was a replacement for an existing C module that could act as a fallback, rather than an entirely new module with no fallback.
ID: 277999
Author: Brénainn Woodsend
Created at: 2025-11-20T23:01:38.607Z
Number: 187
Clean content: In that case, perhaps Python’s build system would have to be pushy and fail without rust by default unless some --use-legacy-c-{module}-implementation flag is given? Otherwise, I suspect that many of the people downstream we want feedback from aren’t going to notice it.
ID: 278001
Author: Neil Schemenauer
Created at: 2025-11-20T23:37:14.235Z
Number: 188
Clean content: I feel the current proposal is so conservative that it doesn’t really get us there. I think that’s okay.  This is going to be a many-year, perhaps on the order of decades, project.  The first step is to add Rust as an optional feature of the CPython build.  That will allow us to solve some tricky problems about how we can make Rust and C co-exist.  And, we can find out how many platforms are going to be affected by this (e.g. they can’t get the optional features to build) and fix that for as many platforms as we can. This initial step doesn’t necessarily help with code safety, API cleanliness, or performance aspects.  I’m sure others will disagree but, to me, the benefits that Rust can bring on those is clearly demonstrated in other projects.  We don’t need to prove those specifically for CPython. Edit: maybe it’s useful to enumerate what I think are the clear benefits that Rust could bring.  I’m not a Rust programmer so knowledgeable people will need to correct me if I’m wrong (as I’m sure they will gleefully do). array bounds checking: in the year 2025, it’s crazy we are using a programming language that doesn’t do this.  Yes, there can be extra overhead.  No, you are not smart enough to get it correct. use-after-free and other memory lifetime bugs.  Rust’s borrow checker avoids most of these at compile time. integer overflow: Rust doesn’t prevent it but at least it defines what happens.  Undefined behavior is bad. scope based cleanup: I’ve heard that the C language standard might eventually be getting something like __attribute__((cleanup(...))) .  It’s probably going to be decades before CPython could actually rely on C compilers supporting that.  This pattern comes up so often and it’s painful we don’t have a built-in language feature that supports it. There are other benefits and conveniences but these are the big ones, IMHO.
ID: 278011
Author: Jeong, YunWon
Created at: 2025-11-21T01:50:22.666Z
Number: 189
Clean content: nas: array bounds checking: in the year 2025, it’s crazy we are using a programming language that doesn’t do this. Yes, there can be extra overhead. No, you are not smart enough to get it correct. use-after-free and other memory lifetime bugs. Rust’s borrow checker avoids most of these at compile time. integer overflow: Rust doesn’t prevent it but at least it defines what happens. Undefined behavior is bad. scope based cleanup: I’ve heard that the C language standard might eventually be getting something like __attribute__((cleanup(...))) . It’s probably going to be decades before CPython could actually rely on C compilers supporting that. This pattern comes up so often and it’s painful we don’t have a built-in language feature that supports it. Adding more details about the points. array bounds checking is on by default, but when the overhead matters, explicitly skipping check is possible for each element access.. integer overflow panics on debug build. it has both checked operation and wrapping operation. checked operation is default on debug build. wrapping operation is default on release build. Of course each operation can be explicitly marked as checked if it is useful for runtime. Otherwise explicitly marking as wrapping is also useful when it is intended.
ID: 278013
Author: H. Vetinari
Created at: 2025-11-21T03:25:13.839Z
Number: 190
Clean content: Neil Schemenauer: I’ve heard that the C language standard might eventually be getting something like __attribute__((cleanup(...))) . It’s probably going to be decades before CPython could actually rely on C compilers supporting that. This is the defer proposal, which currently exists as a TS (like a branch of the C standard). Here’s an overview of the thing (and the procedural reasons for the TS) in blog post format. Clang has a mostly ready PR for this [1] . The GCC patch set is at v5 AFAICT. Long story short, this should be available in compilers relatively soon [2] and may make it into C2y if people like the feature and let people on the committee know. However you’re likely right about the timelines. Anything before 2040 for broad availability (i.e. defer as part of the standard, not a TS, and implemented across all major compilers present on LTS distros) would be wildly optimistic IMO [3] . Who knows how the world (and CPython) looks like by then… check out the number of reactions as a barometer for people’s interest in this ↩︎ MSVC’s C standard conformance has been horrible since C99; you’d be better off using clang-cl on windows than wait for MSVC on anything. They still haven’t gotten C99 or C11 finished, and ~zero for C23. ↩︎ On the other hand, if people were willing to replace MSVC with clang-cl and rely on -fdefer-ts , you could probably do it in 5 years, assuming the benefits are so substantial that this would be worth it. ↩︎
ID: 278044
Author: Antoine Pitrou
Created at: 2025-11-21T11:59:25.837Z
Number: 191
Clean content: Emma Smith: PyO3 already has 8 years of experience for us to steal re-use refining their APIs. You probably meant “borrow”.
ID: 278071
Author: Antoine Pitrou
Created at: 2025-11-21T19:51:28.905Z
Number: 192
Clean content: Ok, here’s a potential exercise if the optional module story isn’t appealing. The memoryview object is written in C and the performance of memoryview.index is currently horrid due to being written in a very naive way . Accelerating it in C involves generic programming in a language that doesn’t provide any decent metaprogramming. But if an alternate implementation of memoryview was written in Rust, then perhaps those accelerations would be much easier to implement (of course, you also need to develop some basic infrastructure for that: for example, a facility to dispatch to different generic specializations depending on the memoryview format ). So we could have an optional implementation of memoryview in Rust, and fallback on the C one on Rust-less platforms.
ID: 278155
Author: Emma Smith
Created at: 2025-11-22T18:11:23.522Z
Number: 193
Clean content: Thank you for bringing this up! I think memoryview could be a very appealing option for demonstrating Rust. Rust’s generics could make index a lot easier to implement as you say. I also think it has made me reconsider where to draw the line of where it is okay to re-write things in Rust. I want to start this by re-iterating that we do not want to go and just re-implement everything and anything in Rust to start with. At least until we have a lot more experience with Rust in CPython, and given contributors time to learn and try working with Rust, we should select up to a few experimental changes to make, and review our experiences after making those changes. Areas re-written in Rust should have a justification for doing so, like memoryview. We should also consider if the most active contributors to that portion of the codebase are comfortable with Rust being introduced. That being said I think we could expand where Rust could be implemented to include built-in objects, or really any part of the interpreter, if we also keep a C fallback of the implementation. For memoryview, we could keep the current implementation as a compile-time fallback and introduce a Rust version that takes advantage of it’s meta-programming (if needed) and generics. This may mean we’d need to maintain two versions of certain parts of the interpreter for a little while, but I think getting more experience across the code base would be worth the extra effort. The maintenance effort of keeping two implementations should be considered  as part of evaluating where to introduce Rust. With C compile-time fallbacks, there should be no cause for concern on portability or bootstrapping. This seems like a nice compromise between the very limited “Rust only in extension modules” and “Rust can go anywhere and we need to figure out bootstrapping”. Obviously the trade-off is maintenance burden, but I think if we’re smart about what parts we implement in Rust, we can minimize the effort. Curious what others think!
ID: 277474
Author: Emma Smith
Created at: 2025-11-17 16:14
Number: 1
Clean content: Introduction We ( @emmatyping , @eclips4 ) propose introducing the Rust programming language to CPython. Rust will initially only be allowed for writing optional extension modules, but eventually will become a required dependency of CPython and allowed to be used throughout the CPython code base (see update here about requiring Rust ). Motivation Rust has established itself as a popular, memory-safe systems programming language in use by a large number of projects. Memory safety is a property of a programming language which disallows out-of-bounds reads and writes to memory, as well as use-after-free errors. Rust’s safety properties are enforced by an ownership mode for code, which ensures that memory accesses are valid. Rust’s memory safety guarantees have been formally proven by the RustBelt project for code that does not use “unsafe” . By adopting Rust, entire classes of bugs, crashes, and security vulnerabilities can be eliminated from code. Due to Rust’s ownership model, the language also enforces thread safety: data races are prevented at compile time. With free-threaded Python becoming officially supported and more popular, ensuring the standard library is thread safe becomes critical. Rust’s strong thread safety guarantees would ease reasoning around multi-threaded code in the CPython code base. Large C/C++ based projects such as the Linux kernel , Android , Firefox , and many others have begun adopting Rust to improve memory safety, and some are already reporting positive results from this approach . Furthermore, Rust has become a popular language for writing 3rd-party extension modules for Python. At the 2025 Language Summit, it was mentioned that 25-33% of 3rd-party Python extension modules use Rust, especially new extension modules . By adopting Rust in CPython itself, we expect to encourage new contributors to extension modules. 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. While there will necessarily be some unsafe operations interacting with CPython’s C API to begin with, implementing the core module logic in safe Rust would greatly reduce the amount of code which could potentially be unsafe. Rust also provides “zero-cost”, well designed implementations of common data structures such as Vectors, HashMaps, Mutexes, and more. Zero cost in this context means that these data structures allow implementations to use higher-level constructs with the performance of hand-rolled implementations in other languages. The documentation for the Rust standard library covers these data structures very thoroughly. By having these zero-cost, high-level abstractions we expect Rust will make it easier to implement performance-sensitive portions of CPython. Rust additionally enables principled meta-programming through its macro system. Rust has two types of macros: declarative and procedural. Declarative macros in Rust are hygienic, meaning that they cannot unintentionally capture variables, unlike in C. This means it is much easier to reason about macros in Rust compared to C. Procedural macros are a way to write Rust code which does token transformations on structure definitions, functions, and more. Procedural macros are very powerful, and are used by PyO3 to ergonomically handle things like argument parsing, class definitions, and module definitions. Finally, Rust has an excellent build system. Rust uses the Cargo package manager , which handles acquiring dependencies and invoking rustc (the Rust compiler driver). Cargo supports vendoring dependencies out of the box, so that any Rust dependencies do not need to be downloaded (see open questions about dependencies). Furthermore, Rust has easy to set up cross-compilation which only requires installing the desired target and ensuring the proper linker is available. In summary, Rust provides many extremely useful benefits that would improve CPython development. Increasing memory safety would be a significant improvement in of itself, but it is far from the only benefit Rust provides. Implementation The integration of Rust would begin by adding Rust-based extension modules to the “Modules/” directory, which contains the C extensions for the Python standard library. The Rust modules would be optional at build time, dependent on if the build environment has Rust available. Integrating Rust with the CPython C API requires foreign function interface (FFI) definitions in Rust to describe the APIs available. A new crate (a library in Rust terminology) cpython-sys will be introduced to handle these FFI definitions. To automate the process of generating Rust FFI bindings, we use bindgen . Bindgen is not only an official Rust project, but also used ubiquitously throughout the Rust ecosystem to bind to C APIs, including in the Linux and Android projects. Bindgen uses libclang at build time to read C headers and automatically generate Rust FFI bindings for the current target. Unfortunately, due to the use of C macros to define some constants and methods, the cpython-sys crate will also need to replicate a few important APIs like PYOBJECT_HEAD_INIT manually. However these should all be straightforward to replicate and few in number. With the C API bindings available in Rust, contributors can call the FFI definitions to interact with CPython. This will necessarily introduce some unsafe Rust code. However extension modules should be written such that there is a minimal amount of unsafe at the edges of FFI boundaries. Eventually safe abstractions to simplify and standardize code like module definitions, function argument parsing, and class definitions could be adopted to reduce the amount of raw FFI code written. A reference implementation which includes a proof-of-concept _base64 module which uses Rust to provide a speedup to base64 is available. Distribution Rust supports all platforms which CPython supports and many more as well . Rust’s tiers are slightly different, and include information on whether host tools (such as rustc and cargo ) are provided. Here are all of the PEP 11 platforms and their corresponding tiers for Rust: Platform Python Tier Rust Tier aarch64-apple-darwin 1 1 with Host Tools aarch64-unknown-linux-gnu (gcc, glibc) 1 1 with Host Tools i686-pc-windows-msvc 1 1 with Host Tools x86_64-pc-windows-msvc 1 1 with Host Tools x86_64-unknown-linux-gnu (gcc, glibc) 1 1 with Host Tools aarch64-unknown-linux-gnu (clang, glibc) 2 1 with Host Tools wasm32-unknown-wasip1 2 2 without Host Tools x86_64-apple-darwin 2 2 with Host Tools x86_64-unknown-linux-gnu (clang, glibc) 2 1 with Host Tools aarch64-linux-android 3 2 without Host Tools aarch64-pc-windows-msvc 3 1 with Host Tools arm64-apple-ios 3 2 without Host Tools arm64-apple-ios-simulator 3 2 without Host Tools armv7l-unknown-linux-gnueabihf (Raspberry Pi, gcc) 3 2 with Host Tools aarch64-unknown-linux-gnu (Raspberry Pi, gcc) 3 1 with Host Tools powerpc64le-unknown-linux-gnu 3 2 with Host Tools s390x-unknown-linux-gnu 3 2 with Host Tools wasm32-unknown-emscripten 3 2 without Host Tools x86_64-linux-android 3 2 without Host Tools x86_64-unknown-freebsd 3 2 with Host Tools In summary, every platform Python supports is supported Rust at tier 2 or higher, and host tools are provided for every platform other than those where Python is already cross-compiled (e.g. WASI and mobile platforms). Rejected Ideas Use PyO3 in CPython While CPython could depend on PyO3 for safe abstractions over CPython C APIs, this may not provide the flexibility desired. If a new API is added to the C API, it would need to be added to PyO3, then the version of PyO3 would need to be updated in CPython. This is a lot of overhead and would slow down development. Using bindgen, new APIs are automatically exposed to Rust. Keep Rust Always-Optional Rust could provide many benefits to the development of CPython such as increased memory safety, increased thread safety, and zero-cost data structures. It would be a shame if these benefits were unavailable to the core interpreter implementation permanently. Open Questions How should we manage dependencies? By default cargo will download dependencies which aren’t already cached locally when cargo build is invoked, but perhaps we should vendor these? Cargo has built-in support for vendoring code. We could also cargo fetch to download dependencies at any other part of the build process (such as when running configure). How to handle binding Rust code to CPython’s C API? The MVP currently uses bindgen, which requires libclang at build time and a number of other dependencies. We could pre-generate the bindings for all supported platforms, which would remove the build-time requirement on vendoring bindgen and all of its dependencies (including libclang) for those platforms. When should Rust be allowed in non-optional parts of CPython? This section is out of date, please see Pre-PEP: Rust for CPython - #117 by emmatyping . Leaving the original for the record. Given the numerous advantages Rust provides, it would be advantageous to eventually introduce Rust into the core part of CPython, such as the Python string hasher, SipHash. However, requiring Rust is a significant new platform requirement. Therefore, we propose a timeline of: In Python 3.15, ./configure will start emitting warnings if Rust is not available in the environment. Optional extension modules may start using Rust In Python 3.16, ./configure will fail if Rust is not available in the environment unless --with-rust=no is passed. This will ensure users are aware of the requirement of Rust on their platform in the next release In Python 3.17, Python may require Rust to build We choose this timeline as it gives users several years to ensure that their platform has Rust available (most should) or otherwise plan for the migration. It also ensures that users are aware of the upcoming requirement. We hope to balance allowing time to migrate to Rust with ensuring that Rust can be adopted swiftly for its many benefits. How to handle bootstrapping Rust and CPython Making Rust a dependency of CPython would introduce a bootstrapping problem: Rust depends on Python to bootstrap its compiler . There are several workarounds to this: Rust could always ensure their bootstrap script is compatible with older versions of Python. Then the process is to build an older version of Python, build Rust, then build a newer version of CPython. The bootstrap script is currently compatible with Python 2, so this seems likely to continue to be the case Rust could use PyPy to bootstrap Rust could drop their usage of Python in the bootstrap process I ( @emmatyping ) plan to reach out to the Rust core team and ask what their thoughts are on this issue. What about platforms that don’t support Rust? Rust supports all platforms enumerated in PEP 11, but people run Python on other operating systems and architectures. Reviewing all of the issues labeled OS-unsupported in the CPython issue tracker, we found only a few cases where Rust would not be available: HPPA/PA-RISC: This is an old architecture from HP with the last released hardware coming out in 2005 and a community of users maintaining a Linux fork. There is no LLVM support for this architecture. RISC OS: This is a community maintained version of an operating system created by Acorn Computers. There’s no support in Rust for this OS. PowerPPC OS X: This older OS/architecture combination has a community of users running on PowerBooks and similar. There is no support in Rust for this OS/architecture combination, but Rust has PowerPC support for Linux. CentOS 6: Rust requires glibc 2.17+, which is only available in Centos 7. However, it is unlikely users on a no-longer-supported Linux distribution will want the latest version of CPython. Even if they do, CPython would have a hard time supporting these platforms anyway. How should current CPython contributors learn/engage with Rust portions of the code base? Current contributors may need to interact with the Rust bindings if they modify any C APIs, including internal APIs. This process can be well covered in the devguide, and there are many great resources to learn Rust itself. The Rust book provides a thorough introduction to the Rust programming language. There are many other resources in addition, such as Rust for C++ programmers and the official learning resources Learn Rust - Rust Programming Language . To ease this process, we can introduce a Rust experts team on GitHub who can be pinged on issues to answer questions about interacting with the API bindings. Furthermore, we can add a Rust tutorial focused on Rust’s usage in CPython to the devguide. Obviously any extension modules written in Rust will require knowledge of Rust to contribute to. What about Argument Clinic? Argument Clinic is a great tool that simplifies the work of anyone writing C functions that require argument processing. We see two possible approaches for implementing it in Rust: Adapt the existing Argument Clinic to parse Rust comments using the same DSL as in C extensions, and generate Rust function signatures. Create a Rust procedural macro capable of parsing a similar DSL. This approach might allow it to be used by any third-party package, whereas the C-based Argument Clinic does not guarantee compatibility with third-party extensions. Using a proc macro would allow for better IDE integration and could become useful to 3rd party extension authors. Should the CPython Rust crates be supported for 3rd-party use? Should there be a Rust API? Having canonical Rust crates for bindings to CPython’s C API would be advantageous, but the project is ill-prepared to support usage by 3rd-parties at this time. Thus we propose deferring making Rust code supported for 3rd-party use until a later date.
ID: 277475
Author: Cornelius Krupp
Created at: 2025-11-17 16:25
Number: 2
Clean content: Isn’t the experience in the linux kernel with adding rust support as a core part more a cautionary tale? At least it looks that way from the outside. There is constant friction between the two different “types of programmers”, causing a lot of quite public disagreement. If rust becomes a requirement for core devs, might that scare away some current maintainers who don’t want to deal with it?
ID: 277478
Author: Kirill Podoprigora
Created at: 2025-11-17 16:32
Number: 3
Clean content: Hello, and thanks for your question! We will try to make this transition as smooth as possible. We’re planning to write a “migration guide” for CPython contributors to help make their adoption of Rust as easy as possible. Can this scare current maintainers? Yes. Will we do everything we can to make sure it doesn’t? Absolutely.
ID: 277480
Author: Jacopo Abramo
Created at: 2025-11-17 16:45
Number: 4
Clean content: I’m not a core dev nor expert in the internals of CPython, but I wanted to chime in to resonate with the question from @MegaIng , pointing out though that it looks to me (as a Python user) that the community in general is more “approachable” in comparison to what happened during the integration of some Rust in the Linux kernel. Out of curiosity, what would this mean for both PyO3 and RustPython ? Have you reached out to the mantainers of the latter for feedback on how to approach this possibility? If so, what’s their opinion? It looks to me like this possible PEP might benefit greatly from their experience (I don’t know if you guys are part of their team, I’m just assuming you’re not but I apologize if that’s incorrect). Also, I’m probably jumping the gun with this question, but since also RustPython seems to be implementing the GIL in a similar fashion, would you expect some challenges in applying PEP 703 efficiently for rust-based extensions? I imagine (or rather, hope) that by the time 3.17 is out that CPython will be completely GIL-less by then. Do you expect that this additional feature will be provided smoothly in Rust extensions as well? Same question applies for the new experimental JIT which should be more stable in future releases. Finally, if I recall rust applications tend to be a bit “bloated” in binary size, although there are some tricks that can be done at compile time to reduce this - what do these tricks imply on performance I have no idea.
ID: 277482
Author: Steve Dower
Created at: 2025-11-17 17:04
Number: 5
Clean content: As a general direction, I’d rather see “optional extension modules” [1] living outside the main repo and brought in later in the build/release process. Presumably such modules have no tight core dependency, or they wouldn’t be able to be optional, and so they should be able to build on pre-release runtimes and work fine with released runtimes (as we expect of 3rd party developers). The bootstrapping position is discussed in the proposed text and determined to be viable. I think this position applies equally well to bootstrapping the modules we theoretically expect people to write that rely on non-core dependencies. Merging in additional modules as part of our release process is fine. Bundling additional sources and optional build steps into the source tarball is fine (if we think that Linux distros will just ignore us when we say “you should include these modules in your Python runtime”). For what it’s worth, I believe that the parts of CPython that directly depend on OpenSSL and Tcl/Tk are also fit for this. So don’t see my position as being about Rust itself [2] - it’s about the direction we should be taking with adding new modules to the core runtime. In short, adding new ways to add new, non-essential modules to the core is counter to the approach we’ve been taking over the last few years. So I’m -1 on adding one. Also optional regular modules. ↩︎ If you want my position about Rust itself, well… it’s not going to help your PEP at all ↩︎
ID: 277483
Author: Alex Gaynor
Created at: 2025-11-17 17:05
Number: 6
Clean content: As I think many folks know, I’ve been quite involved in these sorts of efforts (starting the effort that became Rust for Linux at the PyCon sprints, migrating pyca/cryptography to Rust, and helping to maintain pyo3). As a result, it will come to no one’s surprise that I’m very supportive of this pre-PEP I’m happy to answer any questions folks have about those experiences and lessons learned.
ID: 277485
Author: James Webber
Created at: 2025-11-17 17:17
Number: 7
Clean content: As a Rust fan I think this is super cool! I do wonder if this is too much to figure out in one PEP, when parts of it seems pretty easily separable. I can see how the overall vision fits together, but it’s a lot. Would it make sense to restrict the initial proposal as just “create the cpython-sys crate and allow optional Rust extensions in the stdlib”? That would allow iteration on making a good generic interface [1] without requiring the SC to make a decision on the long-term plan. there is plenty of prior art in PyO3 , and I think the HPy project has some relevance there too ↩︎
ID: 277487
Author: Michael H
Created at: 2025-11-17 17:31
Number: 8
Clean content: I would feel more comfortable with this if it was dependent on custom json targets stabilizing in Rust. Right now, targetting platforms that Rust itself doesn’t support still requires nightly, and python is used to bootstrap a lot of things in a lot of places. I don’t think the impact of this is going to be reasonably predictable, and I’d want there to be a stable upstream escape hatch for those in unusual situations.
ID: 277489
Author: Gundarin Roman
Created at: 2025-11-17 18:17
Number: 9
Clean content: Doesn’t “C“ in the name of “CPython“ means “C programming language”? If so, shouldn’t the project be eventually renamed when a significant part of it is (re)written in Rust? /joke, but who knows
ID: 277490
Author: Da Woods
Created at: 2025-11-17 18:38
Number: 10
Clean content: I’ll start by saying my opinion doesn’t matter here: the number of lines of C I’ve written that’s in the Python interpreter is of the order of 10, so whatever you decide it’s unlikely to be my personal problem. I’m pretty convinced of Rust as a nice language to write cool new things in (and of the value of exposing cool those cool new things to be used from Python). I’m less convinced of the benefit of rewriting existing working things in Rust. [1] So from my point of view this PEP doesn’t offer a lot - it’s largely proposing “rewrite some modules in Rust with a view to soften people up to rewrite more in Rust”. I’d be much more convinced by a PEP that wanted to add something useful to the standard library and had found the best way to do that was to use a Rust library. Minor comment: emmatyping: Rust could use PyPy to bootstrap I suspect this isn’t viable for a couple for reasons: PyPy isn’t hugely well maintained right now, and (I believe) PyPy needs a Python interpreter to bootstrap itself so may not solve the problem. And I think some of the push-pack Rust gets is from when people do this. It’s hard to argue with the benefit of a new and exciting feature but easy to be unimpressed with “what we already have but in Rust”. ↩︎
ID: 277491
Author: Antoine Pitrou
Created at: 2025-11-17 18:48
Number: 11
Clean content: Emma Smith: Eventually safe abstractions to simplify and standardize code like module definitions, function argument parsing, and class definitions could be adopted to reduce the amount of raw FFI code written. A reference implementation which includes a proof-of-concept _base64 module which uses Rust to provide a speedup to base64 is available. This example shows that you really want the safe abstractions for this to be useful. Otherwise you’re doing the same kind of tedious, unsafe, error-prone low-level pointer juggling and manual reference cleanup as in C (hello Py_DecRef ).
ID: 277493
Author: Guido van Rossum
Created at: 2025-11-17 19:06
Number: 12
Clean content: Snarky note: do we eventually have to rename CPython to CRPython? Seriously, I think this is a great development. We all know that a full rewrite in Rust won’t work, but starting to introduce Rust initially for less-essential components, and then gradually letting it take over more essential components sounds like a good plan. I trust Emma and others to do a great job of guiding the discussion over the exact shape that the plan and the implementation should take.
ID: 277494
Author: Nathan Goldbaum
Created at: 2025-11-17 19:13
Number: 13
Clean content: As a PyO3 maintainer IMO it’d be really nice if we could get rid of the need for the pyo3-ffi crate and instead rely on bindgen bindings maintained by upstream. Most of the overhead of supporting new Python versions is updating the FFI bindings. I bet @davidhewitt has opinions about this from the PyO3 maintainer perspective and I’ll defer to him if he disagrees with me about pyo3-ffi .
ID: 277495
Author: Ed Page
Created at: 2025-11-17 19:18
Number: 14
Clean content: emmatyping: How to handle bootstrapping Rust and CPython Making Rust a dependency of CPython would introduce a bootstrapping problem: Rust depends on Python to bootstrap its compiler . There are several workarounds to this: Rust could always ensure their bootstrap script is compatible with older versions of Python. Then the process is to build an older version of Python, build Rust, then build a newer version of CPython. The bootstrap script is currently compatible with Python 2, so this seems likely to continue to be the case Rust could use PyPy to bootstrap Rust could drop their usage of Python in the bootstrap process I ( @emmatyping ) plan to reach out to the Rust core team and ask what their thoughts are on this issue. The specific team involved is T-bootstrap which you can reach out to on zulip at #t-infra/bootstrap
ID: 277496
Author: Chris Angelico
Created at: 2025-11-17 19:18
Number: 15
Clean content: Guido van Rossum: Snarky note: do we eventually have to rename CPython to CRPython? I would strongly advise against that, on account of people inserting an “A” into it More seriously though: Rust has been a focus for a lot of controversy and risk, with massive open questions such as the impact of a potential Ken Thompson style compiler hack . Will CPython lose trust by becoming dependent on a single specific compiler that might be subject to such a hack? Currently, CPython can be compiled using multiple different compilers (I believe gcc, clang, and MSVC are all supported - correct me if I’m wrong?), which mitigates the threat by allowing them to check each other. Adding Rust to the mix will mean that, on every platform, the same Rust compiler MUST be used.
ID: 277497
Author: Paul Ganssle
Created at: 2025-11-17 19:41
Number: 16
Clean content: I have long liked the idea of doing something like this, and as someone who always introduces memory leaks and segfaults and such any time he writes any kind of C extension code, I welcome the idea of more modern zero-cost abstractions for that [1] . However, one cost I think that has not been mentioned here is the effect that this could have on build times. In my experience, compile times for Rust (and C++) are much slower than for C. On my 2019 Thinkpad T480, from a fresh clone of CPython, I can build the whole thing in 2m50s (with make -j , and admittedly it taxes the machine): real	2m50.573s
user	14m57.260s
sys	0m42.975s After the initial build, incremental builds are in seconds. Not sure I know of any projects of comparable size and complexity to compare with, does anyone know if (in the extreme — I know this isn’t the plan) we were to re-write CPython in Rust, how the build times would compare? I really think that the fast iteration time and low overhead from the builds is a great feature of our current build system that I would really hate to give up. I guess the question is a dual one: can we write Rust in a way that it will not cause build times to explode and if we cannot, is the plan to keep the scope of Rust in CPython to a level where building is still very accessible? My thinking is that if build times were 2x slower that would be acceptable if it meant a significant reduction in security critical bugs, but I personally wouldn’t love it if it were much slower than that. On rereading, I realized that this makes it sound like I want zero-cost abstractions to help me introduce more segfaults. If it’s unclear to anyone, I meant “to avoid that”. I have left the original wording because I like to at least initially convey that I am Chaotic Neutral. ↩︎
ID: 277499
Author: Barry Warsaw
Created at: 2025-11-17 19:51
Number: 17
Clean content: Guido van Rossum: Snarky note: do we eventually have to rename CPython to CRPython? Clearly it should be “CrustyPython” But seriously, I’m really excited about this proposal.
ID: 277500
Author: James Webber
Created at: 2025-11-17 19:55
Number: 18
Clean content: In my experience incremental Rust builds are also very fast–the initial setup (including downloading and building all the dependencies) can be slow, but it’s able to do fast incremental builds just fine. Also, there’s a big difference between debug and release mode–building in debug mode is way faster. I would be surprised if this impacted iteration time unless you’re trying to rebuild the world every time.
ID: 277502
Author: danny mcClanahan
Created at: 2025-11-17 20:32
Number: 19
Clean content: I recently elected to try learning C++ after an entire professional career of Rust + Python, because I wanted to make a build system that can be bootstrapped in as few jumps as possible (so that it could be invoked from inside other build systems like cargo or pip). Having worked a lot on the pants build tool in python + rust, I have strong feelings about affordances the build system should provide to users—feelings I will try to quell to achieve a productive discussion. The pants build tool has incorporated rust since Twitter’s “moonshot” rewrite from python-only through 2017-2019—I contributed the current iteration of our python-level interface for cacheable+parallelizable build tasks ( Concepts | Pantsbuild ), which uses pyo3 to hook up rust async methods as “intrinsics” which can be interchanged with “async def” coroutines (Stu Hood originally proposed and implemented this approach)—we’ve had this interop since before async was stable and before pyo3 existed. We used rust, so we had to use cargo. Most of a decade later, we haven’t managed to use our own build system (written in rust) to build the rust code at the heart of our system. I claim that one of the major reasons for this failure is that cargo is almost unique among build systems in providing absolutely no structured mechanisms for: (1) communicating with other package build scripts in the same dependency graph (2) communicating with the downstream user who invokes cargo (such as a distro packager, or a github actions pipeline) This failure is especially notable because of the same powerful guarantees cargo ensures for rust-only dependency graphs, as described in OP: Finally, Rust has an excellent build system. Rust uses the Cargo package manager, which handles acquiring dependencies cargo unfortunately has no standard mechanism for declaring dependencies downloaded within a build script so that they can be audited or overwritten, except the excessively restricted (non-transitive) and poorly documented links key in Cargo.toml, which requires that a build script link a native library into the resulting executable. cargo also has no standard conception of a “toolchain”, or even an ABI outside of rustc output. This can and does mean that build scripts will fail because a dependency was built for a slightly different ABI, because again, not only is there no standard interface for downstream build configuration, but there’s not even a standard interface for communicating structured data across build scripts . So rust devs end up doing the natural thing and using somewhere in ~/.cache or ~/.config or elsewhere as undocumented mutable state. I am relatively confident this isn’t an oversimplification, because bootstrapping the rust compiler itself ends up invoking multiple distinct reimplementations of LLVM target triple parsing, added at different times and never synced up. This is because rustc uses cargo, and cargo does not support structured communication across build scripts. I proposed some of how I wanted to help improve this situation to NGI Zero at the end of last year. This C++ system I mentioned at the beginning is a competing approach, which would replace cargo instead of attempting incremental reform. I’m still not sure of the “right” answer to this—and I don’t think fixing cargo should be the purview of this PEP anyway. But I am personally convinced that if CPython were to integrate rust (possibly even just at phase 1, with only external module support), we (CPython and pypa contributors, of which I am only the latter) would necessarily have to figure out a more structured way to thread ABI info through cargo, and potentially even institute a whole structured communication mechanism across the build script dependency graph. I think that will be a lot of hard work and we should prepare for it earlier rather than later . I am very heartened to read in OP that there are steps being taken to interface with the rustc team to express CPython’s bootstrapping+portability requirements. It sounds like we’re on a good trajectory already to consider the above. I would just urge contributors to consider that pants has not solved cargo’s python packaging difficulties in many years and that it may be worth opening up a greater discussion about cargo affordances in order for cargo (not just rustc) to support CPython’s (and consequently pypa’s) needs.
ID: 277503
Author: Alex Gaynor
Created at: 2025-11-17 20:40
Number: 20
Clean content: pganssle: I guess the question is a dual one: can we write Rust in a way that it will not cause build times to explode and if we cannot, is the plan to keep the scope of Rust in CPython to a level where building is still very accessible? The best things we can do to keep Rust build UX good for core devs (and other contributors): Keep a lean dep tree – and be able to rebuild each module individually (lots of parallelism, like we have in C). Have a easy to use flow that uses cargo check , which does type checking but doesn’t actually compile, since that gives you a very fast devloop.
ID: 277504
Author: David Hewitt
Created at: 2025-11-17 20:43
Number: 21
Clean content: Thank you @emmatyping @eclips4 for proposing this (and @ngoldbaum for the ping)! Very excited to see this initiative and as a proponent of Python, Rust, and the two together, eager to be involved. As a longtime PyO3 maintainer I have been thinking about what this might look like for a while. I asked about exactly this kind of possibility at the Language Summit earlier this year to gauge the temperature for anyone wishing to experiment. The response I heard then was that experimentation towards a concrete proposal was welcome (I hadn’t yet found the time to explore myself, so thank you). I have a number of comments so will try to keep each brief for now and we can expand later if needed. emmatyping: [rejected] Use PyO3 in CPython pitrou: This example shows that you really want the safe abstractions for this to be useful. I completely agree with both of these points. Depending on PyO3 as currently implemented within CPython will introduce unwanted friction. PyO3 also supports PyPy and GraalPy, as well as older versions of CPython (currently back to 3.7). Rust for CPython will presumably not need to support anything other than current CPython. At the same time, CPython will need safe higher-level Rust APIs to get the benefit of Rust. PyO3 has a lot of prior art on the high-level APIs (and hard lessons learned); I think the right approach here will be similar to what attrs did for dataclasses - the Rust APIs implemented by CPython can pick the bits that work best. emmatyping: What about platforms that don’t support Rust? gccrs is an alternative implementation of Rust for GCC backend, which is not yet at feature parity but an important target for Rust for Linux. If CPython was using Rust, I would hope that efforts for non-llvm platforms may be helped by this. emmatyping: What about Argument Clinic? PyO3’s proc macros function a lot like argument clinic - we could potentially reuse parts of their design (and/or implementation); PyO3 might eventually even depend upon any implementation owned by CPython. I would recommend this choice as the more idiomatic way to do codegen in Rust. emmatyping: Should the CPython Rust crates be supported for 3rd-party use? Should there be a Rust API? ngoldbaum: As a PyO3 maintainer IMO it’d be really nice if we could get rid of the need for the pyo3-ffi crate and instead rely on bindgen bindings maintained by upstream. Most of the overhead of supporting new Python versions is updating the FFI bindings. I agree with both of these points; we may want some experience before deciding how CPython would want to commit to supporting these crates. At the same time, having a way to consume in-dev CPython versions immediately in PyO3 would really help with iteration speed for the ecosystem. PyO3 has precedent of “experimental” features for things not yet stable, one middle ground might be to allow PyO3 to have an experimental feature which switches out pyo3-ffi ’s curated FFI bindings for the ones generated by CPython. MegaIng: Isn’t the experience in the linux kernel with adding rust support as a core part more a cautionary tale? At least it looks that way from the outside. There are a couple of takeaways from Rust for Linux that I think are most interesting here: Social questions - inevitably not everyone will want to be using \<insert language X here\>  instead of \<insert language Y here\>. Some current maintainers might churn from not wanting Rust, and other new maintainers may be attracted by the appeal of using it. The Python community places a lot of emphasis on inclusivity and I’d hope we would welcome everyone’s opinions as valid even if eventually a decision driven by the majority must be taken. (Not implying here whether the majority is for or against exploring Rust support; that is the purpose of having these discussions, after all.) Technical opening - Rust for Linux has unsurprisingly become a major strategic focus for the language. I would hope that Rust for CPython would have justification for carrying similar weight in the focus of the Rust project should there be friction where Rust (and cargo etc) do not currently meet CPython’s needs.
ID: 277505
Author: Emma Smith
Created at: 2025-11-17 20:50
Number: 22
Clean content: Note: I’m working on replying to everyone but wanted to get some initial replies out, I appreciate patience with this. Cornelius Krupp: Isn’t the experience in the linux kernel with adding rust support as a core part more a cautionary tale? At least it looks that way from the outside. There is constant friction between the two different “types of programmers”, causing a lot of quite public disagreement. I agree with @jacopoabramo on this, I like to think that the Python community will be better about being productive, amicable, and respectful when discussing these issues. So I think the experience will be altogether different. Jacopo Abramo: Out of curiosity, what would this mean for both PyO3 and RustPython ? Have you reached out to the mantainers of the latter for feedback on how to approach this possibility? If so, what’s their opinion? It looks to me like this possible PEP might benefit greatly from their experience (I don’t know if you guys are part of their team, I’m just assuming you’re not but I apologize if that’s incorrect). I reached out to David Hewitt who has now responded in this thread and will contribute to the effort (thank you, David!) . Kirill has reached out to the RustPython team as well! Jacopo Abramo: would you expect some challenges in applying PEP 703 efficiently for rust-based extensions? On the contrary, it should be much less effort as safe Rust is thread-safe due to the borrow checker. There will need to be some support added to handle integrating attached thread states, but it should be relatively easy. Jacopo Abramo: Same question applies for the new experimental JIT which should be more stable in future releases. Sorry, I’m not sure if you are asking if Rust extensions will work with the JIT or if Rust can be used to implement it? For the former they should work without issue. For the latter the JIT currently relies on a custom calling convention which is not yet exposed in Rust (but is being discussed to do so last I checked). I don’t suggest moving this code to Rust until it is reasonable to implement in Rust and the necessary calling convention features are available. Jacopo Abramo: Finally, if I recall rust applications tend to be a bit “bloated” in binary size, although there are some tricks that can be done at compile time to reduce this - what do these tricks imply on performance I have no idea. This is definitely something to be cognizant of, thank you for bringing it up! There are several strategies which will not affect performance, such as abort on panic, which we can explore. We will probably want to abort on panic anyway since unwinding over FFI layers is UB. Steve Dower: As a general direction, I’d rather see “optional extension modules” living outside the main repo and brought in later in the build/release process. Presumably such modules have no tight core dependency, or they wouldn’t be able to be optional, and so they should be able to build on pre-release runtimes and work fine with released runtimes (as we expect of 3rd party developers). I think this is an interesting proposal, but orthogonal to the current one. We hope Rust will eventually become required to build CPython so it can be used to improve the CPython core. I would suggest splitting this off into it’s own thread to discuss it further. Steve Dower: In short, adding new ways to add new, non-essential modules to the core is counter to the approach we’ve been taking over the last few years. So I’m -1 on adding one. Again I think it is important to highlight that this proposal is more than just _base64 , and more than just optional modules. We’d eventually like to make Rust a hard dependency so it can be used to improve the implementation of the Python runtime as well. Alex Gaynor: I’m happy to answer any questions folks have about those experiences and lessons learned. Thanks Alex! We definitely want to approach this carefully and with thought, your expertise will be invaluable! James Webber: As a Rust fan I think this is super cool! I do wonder if this is too much to figure out in one PEP, when parts of it seems pretty easily separable. I can see how the overall vision fits together, but it’s a lot. I think we necessarily need to make a plan for long term adoption so we can figure out when Rust can be a required dependency and ensure we plan ahead in advance well enough for it. I don’t want to get anyone caught by surprise when suddenly they need Rust to build CPython when they don’t expect it. I will say that the final PEP will probably be what you propose plus a timeline to make Rust a required dependency. Iterating on ergonomic APIs for Rust is definitely something I’d be working on if cpython-sys is approved. Michael H: I would feel more comfortable with this if it was dependent on custom json targets stabilizing in Rust. Right now, targetting platforms that Rust itself doesn’t support still requires nightly, and python is used to bootstrap a lot of things in a lot of places. Perhaps then we can ensure that releases build with an older nightly Rust to enable such bootstrapping? I expect these cases to be relatively uncommon - Rust supports a large number of platforms. Da Woods: So from my point of view this PEP doesn’t offer a lot - it’s largely proposing “rewrite some modules in Rust with a view to soften people up to rewrite more in Rust”. I would restate our goal as “slowly introduce Rust to carefully integrate it and make sure we get things right and give people time to adapt to the significant change.” _base64 is chosen as an example as it is easier to implement, easier to understand, and would only affect performance, so is entirely optional. I think there are several existing modules that could see clear benefits from being written in Rust, eventually . Especially for those that interact with untrusted input such as json, it would be a significant improvement security-wise if we implemented them in a memory safe language. But I also don’t want to rush in and cause breakage. These kinds of changes should be done carefully and when well-motivated. Da Woods: emmatyping: Rust could use PyPy to bootstrap I suspect this isn’t viable for a couple for reasons: PyPy isn’t hugely well maintained right now, and (I believe) PyPy needs a Python interpreter to bootstrap itself so may not solve the problem. Good point re PyPy requiring some bootstrap Python itself! I hope that the approach of using an older CPython will be workable. Antoine Pitrou: emmatyping: A reference implementation which includes a proof-of-concept _base64 module which uses Rust to provide a speedup to base64 is available. This example shows that you really want the safe abstractions for this to be useful. Otherwise you’re doing the same kind of tedious, unsafe, error-prone low-level pointer juggling and manual reference cleanup as in C (hello Py_DecRef ). I absolutely agree, safe abstractions over things like argument parsing and module creation make PyO3 a joy to use. I hope we can collaborate with the PyO3 maintainers and provide similarly pleasant abstractions in CPython core. It will certainly be a high priority. I do think even in this simple example there are examples of safe abstractions that provide benefits. Kirill wrote up an abstraction over borrowing a Py_buffer that automatically releases the buffer on drop, so that it is impossible to forget to do that and cause a bug: cpython/Modules/_base64/src/lib.rs at c9deee600d60509c5da6ef538a9b530f7ba12e05 · emmatyping/cpython · GitHub Guido van Rossum: Seriously, I think this is a great development. We all know that a full rewrite in Rust won’t work, but starting to introduce Rust initially for less-essential components, and then gradually letting it take over more essential components sounds like a good plan. I trust Emma and others to do a great job of guiding the discussion over the exact shape that the plan and the implementation should take. Thank you Guido for your trust and words of support, it really means a lot!
ID: 277506
Author: Jubilee
Created at: 2025-11-17 20:51
Number: 23
Clean content: Speaking in a broad way to answer a broad (“depends on many details”) question: In C, the primary compilation unit is each individual file. In Rust, the primary compilation unit is each entire crate. Rust offers many conveniences over C (e.g. not needing to “forward declare” things in various files) that depend on the fact it can treat crates as individual units. As a result, if you were to, for instance, compare the two languages based on “files compiled” but one is a crate, the results may be surprising. But with thoughtful (or just arbitrary) splitting of code, Rust does allow you to keep iterative builds relatively fast, especially if all the code you haven’t changed is in crates upstream of the one you changed. Paying attention to this is especially important for the -sys crates containing bindings, as bindgen essentially involves running a compiler to generate code and thus is not cheap. It’s worth noting that C also enjoys faster compilation with careful management of inclusions and include-guards on repeatedly-included headers. There are many caveats, exceptions, and and-alsos one can attach to what I just said when things get more specific. Some Rust idioms will not make it faster to build something, due to e.g. use of generics or #[inline] that requires multiple downstream instantiations in multiple downstream crates. And of course there’s ongoing work here, such as relink, don’t rebuild , where some of us are attempting to make it so changes to upstream crates only cause rebuilds of downstream crates if the upstream crate actually changed its public API.
ID: 277507
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.
ID: 277508
Author: Steve Dower
Created at: 2025-11-17 20:55
Number: 25
Clean content: Emma Smith: We’d eventually like to make Rust a hard dependency so it can be used to improve the implementation of the Python runtime as well. Then you force me to factor in my experience in Rust, my experience in mixed-language codebases, and my experience in teams, and come down as a firm -1 on the entire proposal.
ID: 277509
Author: David Hewitt
Created at: 2025-11-17 20:56
Number: 26
Clean content: emmatyping: On the contrary, it should be much less effort as safe Rust is thread-safe due to the borrow checker. There will need to be some support added to handle integrating attached thread states, but it should be relatively easy. I completely agree with this; my experience of updating Rust code based upon PyO3 to support free-threaded Python has been relatively painless. I would even go further and suggest that Rust for CPython may be able to assist with the implementation of free-threaded Python; if there are current stlib extension modules needing to be updated for PEP 703 which lack maintainers, migrating them to Rust may be a way to bring on new maintainers and get them thread-safe at the same time. emmatyping: We will probably want to abort on panic anyway since unwinding over FFI layers is UB. For what it’s worth, PyO3 has a mechanism for carrying panics as Python exceptions through stack frames, but I would agree that for sake of binary size and simplicity, an abort would be good enough (the Rust panic hook could be configured to call into Python’s existing fatal exit machinery).
ID: 277512
Author: Steven Sun
Created at: 2025-11-17 21:07
Number: 27
Clean content: In my previous job, I developed and maintained a large codebase mixing C++, Python, and Rust. I am very familiar with these 3 languages. You can notify me if new Rust code or docs requires review. I support if we can start with some extensions with C/Python fallback. Based on my experience, I want to highlight that certain common practice do not align with Rust. For example, fork() is not usable for many Rust libraries (states may be incorrect after fork). https://stackoverflow.com/questions/60686516/why-cant-i-communicate-with-a-forked-child-process-using-tokio-unixstream
ID: 277513
Author: Dmitry
Created at: 2025-11-17 21:17
Number: 28
Clean content: It’s been such an exciting time for Python lately, with this proposal, lazy imports and frozendicts! Another benefit that you might want to mention in the PEP is how IIUC this would open the door for the possibility of shipping with Python modern Rust-based tooling for dep management, formatting and linting, with all the performance, correctness and community enthusiasm that comes with it.
ID: 277516
Author: Emma Smith
Created at: 2025-11-17 21:38
Number: 29
Clean content: Chris Angelico: More seriously though: Rust has been a focus for a lot of controversy and risk, with massive open questions such as the impact of a potential Ken Thompson style compiler hack . Will CPython lose trust by becoming dependent on a single specific compiler that might be subject to such a hack? I’m not familiar with the risks you speak of. As David Hewitt points out, there is a work in progress implementation using gcc, so while there is currently one compiler, that will not remain the case. Paul Ganssle: I guess the question is a dual one: can we write Rust in a way that it will not cause build times to explode and if we cannot, is the plan to keep the scope of Rust in CPython to a level where building is still very accessible? I mostly will defer to @workingjubilee ’s excellent answer and their expertise. I will add however that build times are dear to my heart, so I think good devguide documentation on setting up a dev environment that is configured for fast incremental builds will go a long way in helping. danny mcClanahan: But I am personally convinced that if CPython were to integrate rust (possibly even just at phase 1, with only external module support), we (CPython and pypa contributors, of which I am only the latter) would necessarily have to figure out a more structured way to thread ABI info through cargo This is a really interesting perspective, thanks Danny! I will say getting cargo to fit into CPython’s current build system was a little tricky. That being said I think the ABI question may be less important until Rust code is exposed to users, which will be after we’ve had a lot of experience working with cargo ourselves and can be planned independently of the initial integration, in collaboration with PyPA. David Hewitt: Very excited to see this initiative and as a proponent of Python, Rust, and the two together, eager to be involved. Very excited to have you join us! We greatly value your expertise on Rust and Python interop. David Hewitt: At the same time, CPython will need safe higher-level Rust APIs to get the benefit of Rust. PyO3 has a lot of prior art on the high-level APIs (and hard lessons learned); I think the right approach here will be similar to what attrs did for dataclasses - the Rust APIs implemented by CPython can pick the bits that work best. This is right along the lines of what I was thinking, so glad we are on the same page David Hewitt: emmatyping: What about platforms that don’t support Rust? gccrs is an alternative implementation of Rust for GCC backend, which is not yet at feature parity but an important target for Rust for Linux. If CPython was using Rust, I would hope that efforts for non-llvm platforms may be helped by this. Excellent point! We should make sure to note this in the PEP. David Hewitt: emmatyping: What about Argument Clinic? PyO3’s proc macros function a lot like argument clinic - we could potentially reuse parts of their design (and/or implementation); PyO3 might eventually even depend upon any implementation owned by CPython. I would recommend this choice as the more idiomatic way to do codegen in Rust. Absolutely, I think this would be a great path forward. I would love if the code could be shared across PyO3 and CPython! David Hewitt: Technical opening - Rust for Linux has unsurprisingly become a major strategic focus for the language. I would hope that Rust for CPython would have justification for carrying similar weight in the focus of the Rust project should there be friction where Rust (and cargo etc) do not currently meet CPython’s needs. Yes, there will likely be a few things upstream that may need some work but probably (hopefully!) less than Linux! James Gerity: 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. If you look at issues labeled type-crash you will see a number of issues, such as Use-after-free due to race between SSLContext.set_alpn_protocols and opening a connection · Issue #141012 · python/cpython · GitHub or heap-buffer-overflow in pycore_interpframe.h _PyFrame_Initialize · Issue #140802 · python/cpython · GitHub or JSON: heap-buffer-overflow in encoder caused by indentation caching · Issue #140750 · python/cpython · GitHub . There are many more. James Gerity: ”What will we do about doubling the number of programming languages in the core” feels important to address up-front. Absolutely, I hope that thorough devguide coverage and good tooling will go a long way in making this experience pleasant. I also think having a team of experts will be useful. James Gerity: It seems to me that an eventual PEP should address ”Why not put that development effort towards RustPython ?” in the Rejected Ideas section Thanks, will add this to the list of rejected ideas to add. I also want to cover other language choices, and a few other things. James Gerity: 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. Hm, what adjustment did you have in mind? Steve Dower: Then you force me to factor in my experience in Rust, my experience in mixed-language codebases, and my experience in teams, and come down as a firm -1 on the entire proposal. I’m sorry to hear that Steve. I’m happy to chat further about your experiences at some point, there are definitely wrong ways of integrating new languages into existing code bases. David Hewitt: For what it’s worth, PyO3 has a mechanism for carrying panics as Python exceptions through stack frames, but I would agree that for sake of binary size and simplicity, an abort would be good enough (the Rust panic hook could be configured to call into Python’s existing fatal exit machinery). That’s good to know! I think we will have to evaluate this (as with many things) and decide based on what our experience finds out. Steven Sun: You can notify me if new Rust code or docs requires review. I support if we can start with some extensions with C/Python fallback. Thanks Steven! It’s been great to see a number of people excited about contributing to CPython in Rust if it were added. Steven Sun: Based on my experience, I want to highlight that certain common practice do not align with Rust. For example, fork() is not usable for many Rust libraries (states may be incorrect after fork). https://stackoverflow.com/questions/60686516/why-cant-i-communicate-with-a-forked-child-process-using-tokio-unixstream fork() + threads is sadness pretty universally, it has been an issue for CPython before, so it’s an issue I’m well aware of. Thanks for bringing it up! Dmitry: Another benefit that you might want to mention in the PEP is how IIUC this would open the door for the possibility of shipping with Python modern Rust-based tooling for dep management, formatting and linting, with all the performance, correctness and community enthusiasm that comes with it. That’s a good point, I’ll make sure to note that in the PEP. I misunderstood this post I think, see my comment below.
ID: 277517
Author: James Gerity
Created at: 2025-11-17 21:41
Number: 30
Clean content: emmatyping: Hm, what adjustment did you have in mind? Nothing in particular. 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.
ID: 277519
Author: Chris Angelico
Created at: 2025-11-17 21:49
Number: 31
Clean content: Emma Smith: Rosuav: More seriously though: Rust has been a focus for a lot of controversy and risk, with massive open questions such as the impact of a potential Ken Thompson style compiler hack . Will CPython lose trust by becoming dependent on a single specific compiler that might be subject to such a hack? I’m not familiar with the risks you speak of. As David Hewitt points out, there is a work in progress implementation using gcc, so while there is currently one compiler, that will not remain the case. The risk, in short, is that rustc could easily include all kinds of code that isn’t obvious to an outside auditor. Ken Thompson demonstrated this using a hack that created a login back door; the same thing could infect a more modern system by secretly downgrading TLS in some way, making it possible for a third party to snoop supposedly-encrypted connections. Perhaps in the future this won’t be as much of a consideration, but that would be then, and this is now. Right now, how can we trust rust? How can we know that a Ken Thompson-style hack hasn’t already been done? How do we ensure that one won’t happen in the future? These are not merely academic questions. Python is a well-trusted language used extensively across the internet; if someone with a strong agenda decided to target it, it would be an absolute catastrophe, not least because of how insidious it would be.
ID: 277520
Author: Kirill Podoprigora
Created at: 2025-11-17 21:52
Number: 32
Clean content: @davidhewitt Hi David, and thank you very much for maintaining pyo3! I have a question that we should probably address in the PEP: Can we integrate MIRI into our workflow? Have you tried using it in pyo3, and what were the results? TL;DR: MIRI is an undefined-behavior detection tool for Rust, so I’m guessing it could be helpful for us
ID: 277525
Author: Paul Moore
Created at: 2025-11-17 22:00
Number: 33
Clean content: Chris Angelico: Right now, how can we trust rust? How can we know that a Ken Thompson-style hack hasn’t already been done? How do we ensure that one won’t happen in the future? These are not merely academic questions. It seems to me that adoption of Rust for various other core system components offers some level of assurance here. While there are still risks, it seems likely that they would be discovered relatively quickly as Rust adoption increases. Particular cases I’m thinking of include: Rust in the Linux kernel The Rust reimplementation of coreutils being adopted for Ubuntu Microsoft including Rust in the Windows kernel While the risk involved in a single compiler implementation remains, the chance of detecting any consequent compromise seems like it’s going to rapidly decrease as projects like the above become more widespread.
ID: 277527
Author: Chris Angelico
Created at: 2025-11-17 22:05
Number: 34
Clean content: Paul Moore: It seems to me that adoption of Rust for various other core system components offers some level of assurance here. While there are still risks, it seems likely that they would be discovered relatively quickly as Rust adoption increases. That means that the potential attack surfaces are many. It doesn’t make the decision right for any other project. To be quite honest, I have these exact same concerns regarding the Rust rewrites elsewhere; but (for example) a Rust-based sudo would require that someone first gain shell access as a non-privileged user, and THEN be able to wield an exploit embedded in sudo. With something that is key to many web sites and other internet-connected services, the attack potential is far more direct. Paul Moore: While the risk involved in a single compiler implementation remains, the chance of detecting any consequent compromise seems like it’s going to rapidly decrease as projects like the above become more widespread. And that would be a strong protection, if the only type of attack were one that hits everything all at once. Unfortunately, as Ken Thompson’s hack proved, this sort of attack can be extremely narrowly targeted. And Python is a juicy target.
ID: 277528
Author: James Webber
Created at: 2025-11-17 22:08
Number: 35
Clean content: Is any language really safe from this? Surely gcc alone is a hugely valuable target for such an attack–how do we know it hasn’t happened? Heck, how do we know it hasn’t happened in CPython ? It seems like this is a separate security discussion that goes far beyond Rust.
ID: 277531
Author: Steven Sun
Created at: 2025-11-17 22:10
Number: 36
Clean content: Rosuav: The risk, in short, is that rustc could easily include all kinds of code that isn’t obvious to an outside auditor. I want to add that this risk is real. Besides the code in rust compiler, Rust support procedural macro which executes user-written code during compilation. It requires a lot of work to fully audit. This happened in Rust community before. One previous event is a well-used library shipping pre-built binary to accelerate procedural macro without notice, causing many worries from users. github.com/serde-rs/serde using serde_derive without precompiled binary opened 11:39PM - 27 Jul 23 UTC closed 03:50PM - 17 Aug 23 UTC decathorpe I'm working on packaging serde for Fedora Linux, and I noticed that recent versi … ons of serde_derive ship a precompiled binary now. This is problematic for us, since we cannot, under *no* circumstances (with only very few exceptions, for firmware or the like), redistribute precompiled binaries.

Right now the fallback I am trying to apply for the short-term is to patch serde_derive/lib.rs to unconditionally include lib_from_source.rs (we don't really care about compilation speed for our non-interactive builds).

I'm wondering, how is the x86_64-unknown-linux-gnu binary actually produced? The workspace layout in this project looks very differently from when I last looked in here ... Would it be possible for us to re-create the binary ourselves so we can actually ship it? Or would it be possible to adapt the serde_derive crate to fall back to the non-precompiled code path if the binary file is missing? Rosuav: how can we trust rust? How about a switch to turn off all rust code?
ID: 277532
Author: Chris Angelico
Created at: 2025-11-17 22:11
Number: 37
Clean content: James Webber: Is any language really safe from this? Surely gcc alone is a hugely valuable target for such an attack–how do we know it hasn’t happened? Heck, how do we know it hasn’t happened in CPython ? The biggest protection is having multiple compilers. Do you want to make sure your gcc hasn’t been infected? Download the source code for gcc, and compile it using clang. This could also be affected, but only if someone has infected BOTH compilers. The more diffferent options there are, the less of a threat this is. The threat is, by definition, only relevant to compiled languages that compile their own compilers. It’s inherent in the bootstrapping. So this can’t happen in CPython as it currently is, unless there’s some way that Python code is being used to generate future versions of the CPython binary, in a way that’s independent of the source code (eg Argument Clinic can’t be that, because the output is right there for everyone to see).
ID: 277534
Author: Steve Dower
Created at: 2025-11-17 22:17
Number: 38
Clean content: I’ll briefly put my security team hat on and say that the security side of this is being way overblown. The risk of a supply-chain attack via the compiler is miniscule compared to the multitude of other options - adding Rust doesn’t make that part worse. 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).
ID: 277536
Author: Emma Smith
Created at: 2025-11-17 22:30
Number: 39
Clean content: Chris Angelico: The biggest protection is having multiple compilers. Do you want to make sure your gcc hasn’t been infected? Download the source code for gcc, and compile it using clang. This could also be affected, but only if someone has infected BOTH compilers. The more diffferent options there are, the less of a threat this is. Given that clang had to be bootstrapped by gcc, I think it is impossible to say that this will work for sure. Steve Dower: I’ll briefly put my security team hat on and say that the security side of this is being way overblown. The risk of a supply-chain attack via the compiler is miniscule compared to the multitude of other options - adding Rust doesn’t make that part worse. Thanks Steve! I appreciate you piping up on this. 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 I have a couple of thoughts on this, and hope @davidhewitt has more since he has thought about this problem probably a lot more than I have First, we can build safe abstractions over unsafe operations which will reduce the amount of unsafe users need to interact with. Furthermore, I expect to start with, a safe core for extension modules can be implemented then exposed to CPython through unsafe FFI procedures. This is an approach that has seen wide success throughout other projects. One of Rust’s strengths is that it allows you to focus on where unsafety occurs. Finally, if more of the interpreter were to become Rust, these portions would presumably have safe Rust interfaces.
ID: 277537
Author: Guido van Rossum
Created at: 2025-11-17 22:31
Number: 40
Clean content: steve.dower: Then you force me to factor in my experience in Rust, my experience in mixed-language codebases, and my experience in teams, and come down as a firm -1 on the entire proposal. Steve, without more details your -1 has no weight. You can’t just argue from authority .
ID: 277538
Author: Aria Desires
Created at: 2025-11-17 22:32
Number: 41
Clean content: 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). I highly recommend reading the article from the Android Security team that the original post linked . In particular, the article focuses on a “near-miss” where they almost shipped one (1) memory safety vulnerability in Rust: This near-miss inevitably raises the question: “If Rust can have memory safety vulnerabilities, then what’s the point?” The point is that the density is drastically lower. So much lower that it represents a major shift in security posture. Based on our near-miss, we can make a conservative estimate. With roughly 5 million lines of Rust in the Android platform and one potential memory safety vulnerability found (and fixed pre-release), our estimated vulnerability density for Rust is 0.2 vuln per 1 million lines (MLOC) Our historical data for C and C++ shows a density of closer to 1,000 memory safety vulnerabilities per MLOC. Our Rust code is currently tracking at a density orders of magnitude lower: a more than 1000x reduction. … The primary security concern regarding Rust generally centers on the approximately 4% of code written within unsafe{} blocks. This subset of Rust has fueled significant speculation, misconceptions, and even theories that unsafe Rust might be more buggy than C. Empirical evidence shows this to be quite wrong. Our data indicates that even a more conservative assumption, that a line of unsafe Rust is as likely to have a bug as a line of C or C++, significantly overestimates the risk of unsafe Rust. We don’t know for sure why this is the case, but there are likely several contributing factors: unsafe{} doesn’t actually disable all or even most of Rust’s safety checks (a common misconception). The practice of encapsulation enables local reasoning about safety invariants. The additional scrutiny that unsafe{} blocks receive. I totally understand the concern but there’s so many big old C(++) projects that have integrated Rust and “safety of the bindings” is an obvious concern everyone has and it just… doesn’t end up being that big of a deal in practice? In practical specific terms, it’s often reported that Rust often makes implicit ownership/lifetime constraints in C APIs explicit and easier to work with. The Rust bindings to C functions can include lifetimes that enforce these contracts (and yes a lot of C APIs map onto lifetimes and ownership well).
ID: 277539
Author: Steve Dower
Created at: 2025-11-17 22:33
Number: 42
Clean content: Guido van Rossum: Steve, without more details your -1 has no weight I’m aware. Happy to chat more with the people interested in driving this forward or evaluating/deciding on it, but there are more than enough opinions here already and I don’t see mine helping drive the discussion forward in any particularly meaningful way (especially given the response to my “keep it contained” concern was “actually, we’re going to make it less contained”).
ID: 277540
Author: William Woodruff
Created at: 2025-11-17 22:34
Number: 43
Clean content: Steven Sun: Besides the code in rust compiler, Rust support procedural macro which executes user-written code during compilation. It requires a lot of work to fully audit. It’s worth noting that Rust’s compile-time code execution (via build.rs ) closely mirrors the style and trust model already assumed by Python packaging (via setup.py ). I’m not extremely familiar with the history of build.rs , but it wouldn’t especially surprise me if setup.py (and Gemfile , etc.) were used as a reference point. (I also think the risk of compile-time code execution in Rust is narrow compared to what already exists: how often do you read the autoconf that your C and C++ dependencies use to codegen shell scripts at build time? We have empirical evidence in the form of xz-utils that attackers find that very appealing!)
ID: 277546
Author: Steven Sun
Created at: 2025-11-17 23:03
Number: 44
Clean content: Still a few important questions: Who will lead this large-scale refactoring? 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?
ID: 277553
Author: Donghee Na
Created at: 2025-11-18 00:01
Number: 45
Clean content: I am basically neutral on adopting Rust, and I think Ruby provides a good reference model. They introduced Rust for their JIT implementation as an optional component, and it is worth studying how they approached. (only using std-lib, except unittest and unittest module are excluded when they release) However, I am cautious about the idea of fully rewriting the CPython codebase in Rust. We have a lot of low level and very optimized C code that Rust cannot express safely. A good example is the computed goto dispatch in the interpreter, which would require a large amount of unsafe code or inline assembly if we tried to reproduce it in Rust. Platform support is also still a concern, and that’s why people are waiting for gcc-rs , because once it is shipped, we can cover over where gcc and clang do. My view is that if we want to move forward, we should begin with an experimental approach. We can start by introducing new, non-essential modules written in Rust and evaluating the results. That feels like a reasonable and safe first step, and it allows us to focus on productivity rather than framing everything around memory safety. 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. From what I understand, the Ruby team adopted Rust mainly because implementing their JIT in Rust was more productive than doing it in C. I think that was one of the major factors behind their choice.
ID: 277554
Author: Jeong, YunWon
Created at: 2025-11-18 00:02
Number: 46
Clean content: People still remember the huge drama from early 2025, but I think we should pay more attention to what Torvalds and Greg K-H recently said at the Open Source Summit Korea just two weeks ago. So, so that’s that’s one thing that has changed for me is that I actually feel like sometimes I need to encourage some of the other maintainers to be more open to to new ideas. If we want to bring up Rust for Linux as an example, we should not only talk about how introducing a new and unfamiliar idea can create conflict among existing maintainers, but also emphasize that leadership plays a role in encouraging the community to embrace such changes.
ID: 277557
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.
ID: 277558
Author: Emma Smith
Created at: 2025-11-18 00:37
Number: 48
Clean content: Brett Cannon: sunmy2019: 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. Brett Cannon: sunmy2019: 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. I agree with everything Brett says above, but also wanted to add that I am going to spend some time over the next few days on community building around Rust in CPython with a goal of kicking off discussions around a lot of the topics brought up here.
ID: 277559
Author: Barry Warsaw
Created at: 2025-11-18 00:45
Number: 49
Clean content: Donghee Na: However, I am cautious about the idea of fully rewriting the CPython codebase in Rust. I would go further and predict that this will never happen, and claim that it shouldn’t be a goal of the Rust-in-Python project.  There are 10**oodles of person-years invested in the CPython core interpreter, and I just don’t see how that will ever be cost effective to rewrite, even as a Ship of Theseus . But that’s not to say we shouldn’t go forward with this experiment, because we’ll better understand the costs and benefits [1] . One of the soft consequences I’m especially interested in is whether this attracts more or fewer core developers contributing to the Rust bits than the C bits.  I don’t remember the numbers, but I vaguely recall some discussion about the number of core devs who are comfortable contributing to the C bits vs the Python bits.  The former is surely a smaller number, and my guess is that even fewer are comfortable in Rust today [2] . and better know the unknown unknowns ↩︎ To be clear, I consider everyone’s contributions, regardless of where or what language, to be incredibly valuable and valued ↩︎
ID: 277560
Author: Emma Smith
Created at: 2025-11-18 00:53
Number: 50
Clean content: Donghee Na: We have a lot of low level and very optimized C code that Rust cannot express safely. A good example is the computed goto dispatch in the interpreter, which would require a large amount of unsafe code or inline assembly if we tried to reproduce it in Rust. I think this is actually a great example where Rust could be a huge improvement over C. There is  interest in the Rust community to implement a safe state machine loop, e.g. this proposal RFC: Improved State Machine Codegen by folkertdev · Pull Request #3720 · rust-lang/rfcs · GitHub . That proposal may not get into Rust, but given the interest I am sure there will be some safe solution implemented eventually. And I would like to re-iterate another point: we absolutely should not re-write things that don’t make sense to. The core interpreter loop itself may not make sense to for a while, but that doesn’t mean other important runtime things can’t be Rust, like thread state management, the parser, and others. Barry Warsaw: I would go further and predict that this will never happen, and claim that it shouldn’t be a goal of the Rust-in-Python project. Well then you’ll be really glad with this blurb I was writing in response to Donghee’s post . Speaking for myself here: The goal of this project should not specifically be to re-write CPython in Rust, but rather iteratively move more C code to Rust over time and reap the benefits for those portions of code. This may end up meaning Python becomes entirely Rust! But I don’t think that will necessarily be the end goal. Barry Warsaw: One of the soft consequences I’m especially interested in is whether this attracts more or fewer core developers contributing to the Rust bits than the C bits. I’m also quite interested in this! Given that we have seen people shifting to Rust for new 3rd-party extension modules I really hope that will translate into more contributors.
ID: 277561
Author: Alex Gaynor
Created at: 2025-11-18 00:59
Number: 51
Clean content: emmatyping: The goal of this project should not specifically be to re-write CPython in Rust, but rather iteratively move more C code to Rust over time and reap the benefits for those portions of code. One thing I do think is worth saying: The highest ROI pieces are going to be modules and perhaps builtin types/functions, which can be implemented entirely in safe Rust with ergonomics high level APIs, reaping performance and developer experience/velocity wins. Something like the GC is at the absolute nadir of the value of Rust: it inevitably requires a decent amount of unsafe and won’t benefit from Rust’s other advantages. And then many other things (e.g., the parser or interpreter loop) are likely to be in the middle in terms of where I’d estimate the ROI is.
ID: 277562
Author: Donghee Na
Created at: 2025-11-18 01:15
Number: 52
Clean content: emmatyping: but that doesn’t mean other important runtime things can’t be Rust, brettcannon: 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. Just to clarify: I love using Rust, and I’m one of the people interested in bringing Rust into CPython. I’ve talked about this topic in the context of JIT because of its practical advantages. @emmatyping What I’m curious about is this: in the current PoC, most of the code uses unsafe blocks. I understand this isn’t Rust’s fault but rather a limitation of the CPython API. Still, how do these modules become memory-safe in the PoC, and how much less do we need to worry about memory safety compared to writing the same code in C? For example, if you could say something like “X% of the code in the base64 module becomes memory-safe,” that would be a helpful metric to highlight. Also, do you have any plans to remove the unsafe blocks in modules like base64 ? If so, could you include that plan in the PEP? Another thing: could you compare build times and performance between the C version (with PGO + LTO) and the Rust build? I think that would make the PEP much more balanced and fair for reviewers.
ID: 277563
Author: Neil Schemenauer
Created at: 2025-11-18 01:19
Number: 53
Clean content: Alex Gaynor: Something like the GC is at the absolute nadir of the value of Rust: it inevitably requires a decent amount of unsafe and won’t benefit from Rust’s other advantages. Based on my recent experience in adding hardware prefetch to the free-threaded GC, I feel like writing in Rust could have provided some good benefit.  For example, implementing the gc_span_stack_t data structure and associated methods would have been easier to write and to review.  I would expect that it also would have prevented this memory leak bug in that code.
ID: 277565
Author: Emma Smith
Created at: 2025-11-18 01:47
Number: 54
Clean content: Donghee Na: What I’m curious about is this: in the current PoC, most of the code uses unsafe blocks. I understand this isn’t Rust’s fault but rather a limitation of the CPython API. Still, how do these modules become memory-safe in the PoC, and how much less do we need to worry about memory safety compared to writing the same code in C? I think this section covers that: Emma Smith: Eventually safe abstractions to simplify and standardize code like module definitions, function argument parsing, and class definitions could be adopted to reduce the amount of raw FFI code written. The current implementation is really a proof of concept, so there are a lot of places it could improve. It started with myself wishing to see how hard it would be to integrate Rust with cargo into our existing build system. A Rust _base64 module in CPython will look a bit different from the current proof of concept I hope. I expect extension modules will likely be able to be to be 80% safe hand-written code or more. That being said, building out the safe abstractions will take time and effort to do properly. So I think I would say, if you want to see something like where I hope to end up, look at PyO3, where the vast majority of hand written code is safe. Donghee Na: Another thing: could you compare build times and performance between the C version (with PGO + LTO) and the Rust build? I think that would make the PEP much more balanced and fair for reviewers. @Eclips4 found that his hand-rolled implementation that does not use any SIMD is about 1.6x faster than the _binascii implementation in use today. It’s hard to make a “fair” compilation speed benchmark because there are many variables that can come into play and knobs that can be tuned. The added Rust code will also necessarily add more compile time because we aren’t removing code by introducing _base64 .
ID: 277566
Author: Brénainn Woodsend
Created at: 2025-11-18 01:51
Number: 55
Clean content: Will the binaries written in rust be able to share a single copy of dependencies and/or the rust runtime? My recollection is that ABI in rust is a forgotten dream and that each library/ or executable ends up with separate copy of all its dependencies plus a big fat core runtime lumped into it, turning a network of little libraries [1] into a network of bloatware. But it’s a long time since my last (unsuccessful) attempt to get into rust so that might no longer be true (assuming that it was ever true). or extension modules in CPython’s case ↩︎
ID: 277567
Author: William Woodruff
Created at: 2025-11-18 02:04
Number: 56
Clean content: Brénainn Woodsend: Will the binaries written in rust be able to share a single copy of dependencies and/or the rust runtime? My recollection is that ABI in rust is a forgotten dream Rust has no problem using the C ABI; from experience, the norm when integrating Rust into existing C codebases is retain existing ABI boundaries and perform dynamic linking in the same ways that the codebase would normally. (There’s a separate issue, which is that fully separate Rust builds tend to prefer static linkage because there’s no stable Rust ABI. But the integration efforts of Chrome, Firefox, etc. are good examples of integration of Rust components into projects that assume the C/C++ ABIs.)
ID: 277571
Author: Jeong, YunWon
Created at: 2025-11-18 02:25
Number: 57
Clean content: Hi, I’m one of the RustPython developers, and during work hours I maintain a tightly-coupled C++/Rust project of about 200k lines. I’d like to comment on some of the points raised in the post and the thread. I’m still getting used to Discourse, so please excuse me about missing quotes. Questions about RustPython RustPython isn’t something that can be considered in this PEP in short term. RustPython and CPython are not semantically compatible across many layers of their implementation. Well, RustPython has a bunch of pure Rust library with excellently working Python stdlibs. it could serve as a reference when introducing Rust versions of certain libraries. I don’t believe it is directly related to this PEP. RustPython has its own approach to running without a GIL, but it’s not compatible with CPython’s nogil direction. 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. bindgen I think there must be a good guidelines on how bindgen should be used. bindgen generates both data structure definitions and function bindings. Function bindings are usually reliable—but data structure definitions often are not. If we rely on bindgen for those, we must run the generated tests to verify compatibility. 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’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. Though while rust-in-cpython focuses on writing stdlib modules, where C doesn’t need to call Rust, there may be limited motivation to use cbindgen. This perspective comes from my experience with mixed C++/Rust projects. CPython being a C/Rust project may lead to fewer issues. clinic 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. When Rust penetrates deeper than the module boundary and this approach breaks down, we’ll have better insight for future decisions anyway. ABI I’m not sure how far Rust implementation will expand, but compared to Pants, CPython’s requirements seem much simpler. If we connect this with the clinic/cbindgen idea, we could enforce a policy that every exported symbol must be declared in a properly generated C header. Since the only stable ABI in Rust is the C ABI, having headers fully specify remains reasonable until Rust APIs are officially exposed to users. Build time Ideally, Rust debug builds shouldn’t be too slow. But many Rust libraries lean heavily on proc-macros, which can significantly impact build times. For example, RustPython has far less code and functionality than CPython, yet it takes ~5× longer to build, and the gap is even bigger for incremental builds. If build time is a major concern, guidelines limits unnecessary proc-macro usage may help. Also, on the external tooling side, we can hope llvm might support faster Rust debug builds later since Python is a priority project for llvm project. I don’t worry about generics in rust-in-cpython. Unlike RustPython, rust-in-cpython must generate C interface, which discourage to abuse generics. From a build-time perspective, keeping one crate per module as _base64 doing now is very appealing. Using unsafe In my opinion, completely eliminating unsafe from base64 isn’t the right goal. Rust guarantees that code outside an unsafe {} block is safe. Anything the compiler cannot verify must be wrapped in unsafe {} . Wrapping unsafe internals in a “safe” API means the programmer is manually guaranteeing safety. Some guarantees can be established through review and careful implementation, but FFI safety often cannot be fully guaranteed due to inherent interface limitations. 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. So instead of trying too hard to remove unsafe , it’s better to encourage properly mark actually unsafe code and minimize them when possible. Rust benefits vs. FFI cost Rust reduces memory-related bugs, but across FFI boundaries, things can actually become less safe than using a single C compiler. The more FFI boundaries exist, the more type information is lost, and the more binding risk increases. Usually, early Rust adoption increases FFI surface area and reduce problems in the rust codebase but also creates new problems at the same time. Then over time, as Rust takes over more internals, the boundary shrinks and things feel cleaner again. From that perspective, starting with modules is a positive direction: a lot of code, limited boundaries. Questions Shipping strategy: Will the Rust extension only support nogil build? If so, that might help reduce some FFI complexity. Duplication: 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? If so, a guideline to have different implementations about same feature will be great. Having separate module paths and build flags would allow experimentation, and then flipping Rust on by default once stable. It will be work like a sort of feature-level incubators. If possible, I’d love to see this code used: GitHub - RustPython/pymath (While working on it, I learned how dealing with FMA is way nicer in Rust than in C. Thanks tim-one.) 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!
ID: 277572
Author: Éric Araujo
Created at: 2025-11-18 02:29
Number: 58
Clean content: Hi, Dmitry: this would open the door for the possibility of shipping with Python modern Rust-based tooling for dep management, formatting and linting Can you expand on this with some specific examples? I can only interpret this as a suggestion that Python releases would include uv and ruff, and it doesn’t make much sense to me. These projects already exist, their adoption does not depend on CPython using Rust itself. And formatters and linters are third-party projects, not developed by python-dev, and chosen by developers. One thing with special status is pip, included via ensurepip, to solve the packaging boostrapping issue.
ID: 277579
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.
ID: 277580
Author: Emma Smith
Created at: 2025-11-18 04:13
Number: 60
Clean content: Éric Araujo: monk-time: this would open the door for the possibility of shipping with Python modern Rust-based tooling for dep management, formatting and linting Can you expand on this with some specific examples? I can only interpret this as a suggestion that Python releases would include uv and ruff, and it doesn’t make much sense to me. Yeah on a re-read I think my earlier comment misinterpreted this message as discussing clippy and rustfmt (Rust tools). So I would say adding Python tooling that is written in Rust to CPython is out of scope for this proposal.
ID: 277581
Author: Raphael Gaschignard
Created at: 2025-11-18 04:22
Number: 61
Clean content: corona10: @emmatyping What I’m curious about is this: in the current PoC, most of the code uses unsafe blocks. I understand this isn’t Rust’s fault but rather a limitation of the CPython API. Still, how do these modules become memory-safe in the PoC, and how much less do we need to worry about memory safety compared to writing the same code in C? For example, if you could say something like “X% of the code in the base64 module becomes memory-safe,” that would be a helpful metric to highlight. To expand on this point, I see Rust as a potential usability gain here, much more than the security aspect. I think the argument to use Rust for CPython here would be much stronger if we could see standard_b64encode implemented in a way that takes advantage of Rust’s RAII to reduce the book-keeping we have to do in the C code right now. Without a “Rust API” here for writing these extensions, this becomes purely a security argument (that I find fairly unconvincing at some level). If standard_b64encode was returning a Result and we were able to use ? and all this other stuff with a wrapper that did “the right thing” that would be, at least to me, much more interesting EDIT: though a point against this being easy might be the memory allocation story here… though the error allocation failure paths are about allocation failures in the Python arena, not sure if that means we really have no stack left over. Still think it’s worth proving the point that this has ergonomics improvements, because that feels like a pretty big deal all things considered!
ID: 277583
Author: Emma Smith
Created at: 2025-11-18 04:40
Number: 62
Clean content: Raphael Gaschignard: I think the argument to use Rust for CPython here would be much stronger if we could see standard_b64encode implemented in a way that takes advantage of Rust’s RAII to reduce the book-keeping we have to do in the C code right now. Without a “Rust API” here for writing these extensions, this becomes purely a security argument (that I find fairly unconvincing at some level). If standard_b64encode was returning a Result and we were able to use ? and all this other stuff with a wrapper that did “the right thing” that would be, at least to me, much more interesting One example of reducing mental bookkeeping is the BorrowedBuffer abstraction in the implementation cpython/Modules/_base64/src/lib.rs at c9deee600d60509c5da6ef538a9b530f7ba12e05 · emmatyping/cpython · GitHub . As mentioned previously, the current example is pretty bare-bones as it is a proof of concept. There is a large room for improvement in ergonomics. But even with raw FFI bindings, it’s possible to have a safe, idiomatic Rust core of an extension module then expose that via unsafe wrappers. And I think even that will improve the safety and utility of writing extensions in CPython.
ID: 277590
Author: Raphael Gaschignard
Created at: 2025-11-18 04:56
Number: 63
Clean content: Yeah I think the BorrowedBuffer is a good example of helping a bit with its Drop . I guess this would be more convincing to me (random person who has little stake in this beyond poking in CPython internals from time to time but wants to see some idea of this succeed!) if we go a bit further in the barebones interpretation to prove some idea of improved ergonomics, focused entirely on this encode implementation, which includes just enough bookkeeping futzing that would be nice to not see anymore: let result = unsafe {
        PyBytes_FromStringAndSize(ptr::null(), output_len as Py_ssize_t)
    };
    if result.is_null() {
        return ptr::null_mut();
    } instead being something like: let Ok(result) = PyBytes::from_string_and_size(ptr::null(), output_len as Py_ssize_t) else { return ptr::null_mut() } ; Or even, if there’s some way to make PyResult -y thing that could collapse the common CPython errors nicely (maybe not a possible thing!): let result = PyBytes::uninit_from_size(output_len)? Just like BorrowedBuffer , it feels like there could be some single-field wrapper structs, and smart constructors that could operate in a “Rust API”-y level to work off of results Similarly in: let dest_ptr = unsafe { PyBytes_AsString(result) };
if dest_ptr.is_null() {
    unsafe {
        Py_DecRef(result);
    }
    return ptr::null_mut();
} I would have expected we could have some Rust-y wrapper on references that would give us that Py_DecRef call for free just through RAII. And maybe I’m too optimistic of Rust’s compiler toolchain, but if the wrapper was a single field struct, my impression is we would be able to get that for free. The thing I would assume is that within the extension module we could go full Rust API goodness, and it’s only really at the entry and exit points that one would need to go back to acknowledging CPython’s realities a bit more. Anyways yeah, I’m very curious what the ‘pie in the sky most of the APIs used in the encoding example have a nice API’ version of the encode port looks like, because jumping from C to Rust could make the maintenance barrier seem way lower. We don’t have to port everything, just enough and enough smoke and mirrors to say “this is what it looks like in practice for this one method”. Because right now beyond the platform support tradeoffs etc, the PoC example is also presenting as generally more code, not less. In my mind’s eye we wouldn’t even have a tradeoff here, and the code would be simpler.
ID: 277593
Author: Emma Smith
Created at: 2025-11-18 05:05
Number: 64
Clean content: Interactions between Python objects and borrows is rather complicated. I don’t think this thread is a great place to go over detailed API design discussion as that isn’t the goal of the PEP, but I’d be happy to chat in another forum like the Python Discord or via DM. I will say a pie-in-the-sky API will look somewhat like an implementation using PyO3 . I can write up such an implementation and share that if people think it would informative.
ID: 277594
Author: Dan
Created at: 2025-11-18 05:09
Number: 65
Clean content: but eventually will become a required dependency of CPython What does this mean for projects that embed CPython inside their C++ projects? Boost::python or pybind11?
ID: 277596
Author: Emma Smith
Created at: 2025-11-18 05:18
Number: 66
Clean content: You would need Rust to build any Rust extension modules you want in your embedded Python. I believe most embedding links to libpython so that would already be built and wouldn’t require Rust.
ID: 277597
Author: Dan
Created at: 2025-11-18 05:26
Number: 67
Clean content: Emma Smith: You would need Rust to build any Rust extension modules you Thank you, I know nothing of Rust, I see the word ‘dependency’ and I immediately get scared. Python and all the 3rd party modules must load into the host application’s process. In my case, I’m running Python inside AutoCAD for windows. If this is optional, or something that’s not going load some sort of runtime, or something that could cause issues, then great
ID: 277598
Author: Dmitry
Created at: 2025-11-18 05:40
Number: 68
Clean content: Éric Araujo: Can you expand on this with some specific examples? I can only interpret this as a suggestion that Python releases would include uv and ruff, and it doesn’t make much sense to me. We do already ship with pip and pymanager, and there’s no denying that Rust/Go have created an expectation for modern languages to include quality standard dev tooling. And it is equally apparent that the best Python tooling for the next decade will be written in Rust [1] . So I don’t see a future where Python also ships with such tools as outside the realm of possibility [2] . So I don’t see why not. This is clearly out of scope for this proposal, which is why I framed it only as a future possibility – one that would require its own difficult discussion and the platform/build support this PEP addresses. So I won’t pursue this further here. regardless of if it’s still Astral tools like uv and ruff (or ty when it reaches stable) or something else like pyrefly ↩︎ I do believe replacing pip with uv might just be the most widely applauded move Python can make ↩︎
ID: 277601
Author: Jeong, YunWon
Created at: 2025-11-18 07:32
Number: 69
Clean content: To achieve good ergonomics, we’ll need not only cpython-sys but also another crate built on top of it that provides proper Rust abstractions. (Following naming conventions, it would be called cpython , but that name is already taken.) Right now, the PEP only covers cpython-sys , but if we expect Rust ergonomics by this PEP, I think some consideration of this additional crate should also be included.
ID: 277602
Author: Michał Górny
Created at: 2025-11-18 07:39
Number: 70
Clean content: This would be unfortunate for Gentoo. We’re currently one of the few Linux distributions that aim to provide a reasonable working experience for people with older, weaker or more niche hardware that is not supported by Rust; and given that we’re largely talking about volunteers with no corporate backing, there is practically zero chance of ever porting LLVM and Rust to the relevant platforms, let alone providing long-term maintenance needed for keeping them working in projects with such a high rate of code churn. I do realize that these platforms are not “supported” by CPython right now. Nevertheless, even though there historically were efforts to block building on them, they currently work and require comparatively little maintenance effort to keep them working. Admittedly, the wider Python ecosystem with its Rust adoption puts quite a strain on us and the user experience worsens every few months, we still manage to provide a working setup. The moment CPython starts requiring Rust, this will no longer be possible. Of course, we will still be able to provide older versions of CPython for a few years, at least until some major package starts requiring the newer Python version. That said, I do realize that we’re basically obsolete and it’s just a matter of time until some projects pulls the switch and force us to tell our users “sorry, we are no longer able to provide a working system for you”. I don’t expect to change anything here. Just wanted to share the other perspective.
ID: 277603
Author: Stephan Sokolow
Created at: 2025-11-18 08:27
Number: 71
Clean content: I hope nobody will mind if my first post as a complete newcomer to the forum (though very far from one with Python or Rust) is letting my designed-to-win-trivia-games brain provide some context, clarifications, etc. for various things across the thread as a whole. Also, sorry for splitting this across multiple posts but, even after pessimizing all my citations to “Search for …” annotations, it was still claiming I had more than two links in it. (If this posts, then I guess it meant two reply-to-post embeds.) Pre-PEP: Rust for CPython Core Development I’m not a core dev nor expert in the internals of CPython, but I wanted to chime in to resonate with the question from @MegaIng , pointing out though that it looks to me (as a Python user) that the community in general is more “approachable” in comparison to what happened during the integration of some Rust in the Linux kernel. 
Out of curiosity, what would this mean for both PyO3 and RustPython ? Have you reached out to the mantainers of the latter for feedback on how to approach this possibilit… Finally, if I recall rust applications tend to be a bit “bloated” in binary size, although there are some tricks that can be done at compile time to reduce this - what do these tricks imply on performance I have no idea. The answer depends on how long ago you remember that from. Rust’s history has been a tale of improving defaults on this front and I don’t know where you draw the line on “bloated”. For example, prior to Rust 1.28 (Search for “Announcing Rust 1.28” site:blog.rust-lang.org ), some platforms embedded a copy of jemalloc but it now defaults to the system allocator. Rust still statically links its standard library, which is distributed as a precompiled “release + debug symbols” artifact to be shared between release and debug profiles and, for much of its life, there was no integrated support for stripping the resulting binaries. According to the Profiles (Search for “The Cargo Book” “Profiles” site:doc.rust-lang.org ) section of The Cargo Book, strip = "none" is still the default setting for the release profile. If I do a simple cargo new and then cargo build --release the resulting “Hello, World!”, the binary is 463K, which drops to 354K if the debuginfo is stripped. That remaining size includes things like a statically linked copy of libunwind which wouldn’t be needed if using abort on panic as mentioned by Emma Smith… but I’m not up to speed on how much of that will get stripped out without rebuilding the standard library to ensure it isn’t depending on them. (See my later mention of how the Rust team are currently prioritizing stabilizing -Zbuild-std as part of letting “remove kernelspace Rust’s dependency on nightly features” shape much of the 2025 roadmap.) Beyond that, one potentially relevant piece of tooling is dragonfire ( amyspark/dragonfire on the FreeDesktop Gitlab) as introduced in Linking and shrinking Rust static libraries: a tale of fire. (Search for “Linking and shrinking Rust static libraries: a tale of fire” site:centricular.com ) (Which is concerned with deduplicating the standard library when building Rust-based plugins as static libraries.) Pre-PEP: Rust for CPython Core Development Doesn’t “C“ in the name of “CPython“ means “C programming language”? If so, shouldn’t the project be eventually renamed when a significant part of it is (re)written in Rust? 
/joke, but who knows Just declare “CPython” to be referring to the stable ABI exposed rather than the implementation language. After all, the abi_stable crate for dynamically linking higher-level Rust constructs does it by marshalling through the C ABI.
ID: 277604
Author: Stephan Sokolow
Created at: 2025-11-18 08:28
Number: 72
Clean content: Pre-PEP: Rust for CPython Core Development I have long liked the idea of doing something like this, and as someone who always introduces memory leaks and segfaults and such any time he writes any kind of C extension code, I welcome the idea of more modern zero-cost abstractions for that [1] . 
However, one cost I think that has not been mentioned here is the effect that this could have on build times. In my experience, compile times for Rust (and C++) are much slower than for C. On my 2019 Thinkpad T480, from a fresh clone of CPython, I ca… I guess the question is a dual one: can we write Rust in a way that it will not cause build times to explode and if we cannot, is the plan to keep the scope of Rust in CPython to a level where building is still very accessible? I don’t see why it needs to be slow. As laid out in The Rust compiler isn’t slow; we are. (Search for "The Rust compiler isn't slow; we are." site:blog.kodewerx.org ), rustc is already faster than compiling C++ with GCC and the reason builds are slow has more to do with how much the Rust ecosystem enjoys the creature comforts of macros and monomorphized generics. Pre-PEP: Rust for CPython Core Development In my experience incremental Rust builds are also very fast–the initial setup (including downloading and building all the dependencies) can be slow, but it’s able to do fast incremental builds just fine. 
Also, there’s a big difference between debug and release mode–building in debug mode is way faster. I would be surprised if this impacted iteration time unless you’re trying to rebuild the world every time. …and they’re working on making it faster still. Aside from “Relink, Don’t Rebuild”, as mentioned by Jubilee, there are two bottlenecks which disproportionately affect incremental rebuilds right now: First, while there’s parallelism between crates and in the LLVM backend, the rustc frontend is single-threaded. Work is in progress and testable in nightly (Search for “Faster compilation with the parallel front-end in nightly” site:blog.rust-lang.org ) for making the frontend multithreaded. They’re also working on rustc_codegen_cranelift ( rust-lang/rustc_codegen_cranelift on GitHub) which is a non-LLVM backend for rustc which makes more Go-like trade-offs for compile-time vs. runtime performance and is intended to eventually become the default for the debug profile. Second, linking. They’ve been rolling out LLD as a faster default linker on a platform-by-platform basis and it came to Linux in 1.90. (Search for “Announcing Rust 1.90.0” site:blog.rust-lang.org ) Beyond that, mold is faster still (it’s what I use on my system) and wild ( davidlattimore/wild on GitHub), yet faster, is being developed with an eye toward becoming default for debug builds alongside rustc_codegen_cranelift. (i.e. Doesn’t cover all the needs of a fully general-purpose linker, but does make debug builds for the majority of them very quick.)
ID: 277605
Author: Stephan Sokolow
Created at: 2025-11-18 08:29
Number: 73
Clean content: I claim that one of the major reasons for this failure is that cargo is almost unique among build systems in providing absolutely no structured mechanisms for: (1) communicating with other package build scripts in the same dependency graph (2) communicating with the downstream user who invokes cargo (such as a distro packager, or a github actions pipeline) This is a known problem that’s been discussed more or less since v1.0 came out in 2015 but more pressing issues keep jumping ahead of it in the queue. (eg. The 2025H2 roadmap is prioritizing stabilizing an MVP of -Zbuild-std so that embedded and low-level projects like Rust for Linux (i.e. kernelspace Rust) don’t need to use either a nightly compiler or the secret switch to use API-unstable features on stable channel.) If you want to search up existing discussions, what was done to incorporate Rust builds into Bazel got mentioned a lot. Pre-PEP: Rust for CPython Core Development Nothing in particular. 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. It should be noted that, if I understand “GCC Testing Efforts” site:gnu.org correctly, GCC’s support for all platforms would count as “Tier 3, at varying degrees of stubbornness” by Rust testing standards since I don’t see any mention of any of the “Current efforts” entries being integrated to the same “CI on every push and will block merging into main if it fails” degree. Rust’s approach to Tiers 1 and 2 leans in the direction of “We don’t trust our testing to be sufficient for Continuous Deployment, but we’ll do it as diligently as if we were pushing directly to stable channel”. EDIT: …and, apparently, there’s also a limit on number of posts for new users so I can’t get it all in without breaking the rule about no substantial edits. I’ll drop an in-reply-to-embed and add a GitHub Gist containing the source for the entire thing as it was before I started making any changes to try to crunch it in. In total, the posts being replied to, as represented in the auto-updating Discourse permalink URLs, are 4, 9/12, 15, 16, 18, 19, 30, and 38, and a few I forgot to grab URLs for while blockquoting, and the bits which don’t fit include an answer to the concern about Trusting Trust attacks, a clarification about “Rust guarantees that code outside an unsafe {} block is safe”, a mention of #[repr(transparent)] , and a few other little things.
ID: 277606
Author: GalaxySnail
Created at: 2025-11-18 08:30
Number: 74
Clean content: If python cannot be built without rust in the future, I believe the difficulties this would bring to bootstrapping are being underestimated. Python is such a widely used programming language that many projects have started to use python during the build stage. For example, glibc and gcc require python to build ( https://github.com/fosslinux/live-bootstrap/commit/69fdc27d64ec56ad59b83b99aab0747c9d9f81ed ). If python depends on rust, it would mean that all projects using the meson build system would also need rust to bootstrap (I know muon can be a replacement, but muon isn’t 100% compatible with meson). The live-bootstrap project has already completed the bootstrap of python, and it currently requires a total of 11 builds to obtain CPython 3.11.1, including regenerating all generated code ( https://github.com/fosslinux/live-bootstrap/blob/master/parts.rst#159python-201 ). And even when using mrustc to build rust 1.74.0, it still requires 18 builds to obtain rust 1.91, especially since the time required to build rustc is much longer than CPython. Moreover, rust releases a new version every 6 weeks, so this number will grow quickly. Compilation time is also an issue. Although incremental builds in debug mode may be fast, this is not always possible, for example when doing distribution packaging, when using git bisect , or when debugging bugs that only reproduce in release mode. Currently, a full CPython build is still relatively fast, and I agree that it would be acceptable if the full build time were up to 2x slower. Regarding the previously mentioned issue with os.fork , I am not sure whether using fork in a single-threaded process is safe. If using fork in a single-threaded process would still break rust’s safety guarantees, then os.fork and multiprocessing.get_context("fork") would become completely unusable, and that would break many third-party libraries that depend on it. On the other hand, rust occasionally introduces breaking changes outside of editions, for example https://github.com/rust-lang/rust/issues/127343 , and the potential impact of such risks on CPython should be considered carefully.
ID: 277609
Author: David Hewitt
Created at: 2025-11-18 09:21
Number: 75
Clean content: Eclips4: Can we integrate MIRI into our workflow? I spoke to some of the Miri maintainers about running PyO3 through Miri a while ago, I believe back then there were limitations due to all the C FFI being opaque to Miri. I vaguely recall the conversation concluded those limitations could be lifted, would just need some work. I’m not aware of anything to make me think that work has been done yet. 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). At the moment PyO3 has two abstractions, the low level FFI which this pre-PEP proposes generating with bindgen and the high-level abstractions which are totally safe. I’ve wondered about a third level which sits between the two; it would still use unsafe extern “C” ABI and call the C symbols directly, but the types for input & output could encode the possible states, e.g. BorrowedPtr(*mut PyObject) or even Option<NonNull<PyObject>> to force null checking. As long as these are layout identical with the actual C type passed through the FFI, it would just improve type safety without actually introducing any overheads or much “high level” API. There is a lot of scope to experiment here. Gankra: In practical specific terms, it’s often reported that Rust often makes implicit ownership/lifetime constraints in C APIs explicit and easier to work with. The Rust bindings to C functions can include lifetimes that enforce these contracts (and yes a lot of C APIs map onto lifetimes and ownership well). I agree fully with this - in particular a huge win is that you don’t need to remember to call Py_Clear / Py_DecRef / Py_XDecRef on every error pathway, RAII abstractions can just solve this for you. Your point here also speaks to what I was musing about in the point above. barry: The former is surely a smaller number, and my guess is that even fewer are comfortable in Rust today . Absolutely true that while many core devs may not currently be comfortable in Rust, there is a lot of anectotal evidence that after an initial learning curve many people find Rust relatively easy to feel productive and comfortable in. (Google’s experience with Android strongly supports this, for example.) CEXT-Dan: Thank you, I know nothing of Rust, I see the word ‘dependency’ and I immediately get scared. Python and all the 3rd party modules must load into the host application’s process. In my case, I’m running Python inside AutoCAD for windows. If this is optional, or something that’s not going load some sort of runtime, or something that could cause issues, then great Many Python packages are already built in Rust, they’re precompiled and uploaded to PyPI as binary distributions which users can use without any awareness they’re built in Rust. CPython using Rust as an implementation detail would be no different for anyone not building from source. mgorny: Admittedly, the wider Python ecosystem with its Rust adoption puts quite a strain on us and the user experience worsens every few months, we still manage to provide a working setup. @mgorny the Python ecosystem user experience is important to me and I’m aware there have been pains as tooling has adopted to Rust support. Gentoo particularly runs into these pains due to so much from-source building and extensive hardware support. I’m sure I’m not aware of every possible configuration, please always do feel free to ping me / direct me at things and I will do my best to help. I build PyO3 / integrate Python & Rust to empower more people to write software, not to alienate.
ID: 277610
Author: Stephan Sokolow
Created at: 2025-11-18 09:33
Number: 76
Clean content: On the other hand, rust occasionally introduces breaking changes outside of editions, for example I don’t think it’s fair to call Rust out for that specifically, given that it’s not a Rust-specific problem and that, as demonstrated in places like graydon2’s retrobootstrapping rust for some reason , my prior mention of which got spilled into the GitHub Gist because “New users can’t…”, "Modern clang and gcc won’t compile the LLVM used back then (C++ has changed too much – and I tried several CXXFLAGS=-std=c++NN variants!) Modern gcc won’t even compile the gcc used back then (apparently C as well!) Modern ocaml won’t compile rustboot (ditto) While I don’t have numbers, given that Rust’s regression suite became a bottleneck on development before Microsoft started donating Azure time, and that they have Crater (a bot for testing proposed changes against slices of the public crate registry up to and including “all of it”), I suspect Rust introduces breaking changes less than C and C++ do.
ID: 277613
Author: Sergey "Shnatsel" Davidoff
Created at: 2025-11-18 10:26
Number: 77
Clean content: Rosuav: open questions such as the impact of a potential Ken Thompson style compiler hack . Will CPython lose trust by becoming dependent on a single specific compiler that might be subject to such a hack? There is an alternative Rust compiler implementation in C++, mrustc , that implements just enough Rust to compile the official Rust the compiler without relying on it in any capacity. The official Rust compiler bootstrapped both ways (original chain and mrustc) produce identical binaries, which is sufficient to prove the absence of the Ken Thompson hack.
ID: 277614
Author: Sam James
Created at: 2025-11-18 10:42
Number: 78
Clean content: It should be noted that, if I understand “GCC Testing Efforts” site:gnu.org correctly, GCC’s support for all platforms would count as “Tier 3, at varying degrees of stubbornness” by Rust testing standards since I don’t see any mention of any of the “Current efforts” entries being integrated to the same “CI on every push and will block merging into main if it fails” degree. Rust’s approach to Tiers 1 and 2 leans in the direction of “We don’t trust our testing to be sufficient for Continuous Deployment, but we’ll do it as diligently as if we were pushing directly to stable channel”. I don’t really want to derail this thread into a discussion on models of testing, but a similar discussion was had the other week on lobste.rs . I don’t think it’s a accurate summary to say Rust’s ‘testing standards’ just mean ‘Tier 3’ for GCC.
ID: 277616
Author: Stephan Sokolow
Created at: 2025-11-18 10:45
Number: 79
Clean content: Thank you. Is there any chance that clarification could be added to GCC Testing Efforts - GNU Project since that’s what shows up in search results?
ID: 277617
Author: Sam James
Created at: 2025-11-18 10:45
Number: 80
Clean content: In the thread, I did promise to work on improving documentation, so yes, it will be done. EDIT: Filed PR122742 for that.
ID: 277620
Author: Marc-André Lemburg
Created at: 2025-11-18 11:07
Number: 81
Clean content: I’m a firm -1 on proceeding in this direction. The reference implementation CPython is called CPython for a reason, after all, By adding additional requirements, we make CPython less portable, maintenance a lot harder and complicate adoption in spaces where you need to recompile the whole package to other platforms such as WASM. Besides, there already is a GitHub - RustPython/RustPython: A Python Interpreter written in Rust effort. I’m sure they’d love to get more support. If you want to use Rust for writing optional extensions, that’s perfectly fine, but please upload them to PyPI instead of requiring Rust in the CPython core.
ID: 277621
Author: Jacopo Abramo
Created at: 2025-11-18 11:19
Number: 82
Clean content: Members of both the RustPython community and PyO3 already expressed their interest in this approach, as already pointed out from the previous replies on this thread.
ID: 277622
Author: Antoine Pitrou
Created at: 2025-11-18 11:24
Number: 83
Clean content: David Hewitt: I spoke to some of the Miri maintainers about running PyO3 through Miri a while ago, I believe back then there were limitations due to all the C FFI being opaque to Miri. I vaguely recall the conversation concluded those limitations could be lifted, would just need some work. I’m not aware of anything to make me think that work has been done yet. And conversely, would a ASAN/UBSAN build of CPython be able to see/instrument the Rust parts? Otherwise, not seeing the full program execution could impair the ability of the instrumentation to find bugs at runtime.
ID: 277623
Author: Josh Cannon
Created at: 2025-11-18 11:49
Number: 84
Clean content: barry: One of the soft consequences I’m especially interested in is whether this attracts more or fewer core developers contributing to the Rust bits than the C bits. Anecdata: I don’t plan on writing any (more) C code, so outside of all the non-coding ways that exist, I don’t see myself ever meaningfully becoming a contributor to CPython (‘s core). On the other hand, I can’t write enough Rust to scratch the itch. And I don’t think I’m particularly unique or special here
ID: 277625
Author: David Hewitt
Created at: 2025-11-18 12:00
Number: 85
Clean content: pitrou: And conversely, would a ASAN/UBSAN build of CPython be able to see/instrument the Rust parts? ASAN can definitely work with the caveat that this is a nightly Rust feature at present - sanitizer - The Rust Unstable Book UBSAN - I’m less sure, I suspect that the C parts would be instrumented, the Rust parts would not, I would think this would not impact getting meaningful value from the sanitizer.
ID: 277628
Author: Kivooeo
Created at: 2025-11-18 12:30
Number: 86
Clean content: Hi from the Rust Compiler Team! As someone who programmed in Python for several years previously, I’m really excited to see this! I haven’t read the entire thread, but I have a minor concern that I previously raised personally with Kirill and wanted to bring here as well. After reading the PEP, one question remains regarding the specific version of Rust that will be used in Python. While Rust maintains excellent stability for the vast majority of users, large foundational projects like CPython often benefit from more conservative versioning strategies. Following approaches used by other large projects, would it make sense to pin specific Rust versions and update deliberately. Additionally, the policy around nightly features isn’t entirely clear. These often contain some quality-of-life improvements that might assist development. Within the Rust compiler itself, we regularly rely on many nightly features, so their treatment remains an open question from the PEP. These are the main points that I feel still need clarification after reading the proposal. Thank you for your tremendous work on integrating Rust into Python – it will be very exciting to watch this progress!
ID: 277633
Author: Michał Górny
Created at: 2025-11-18 12:55
Number: 87
Clean content: davidhewitt: mgorny: Admittedly, the wider Python ecosystem with its Rust adoption puts quite a strain on us and the user experience worsens every few months, we still manage to provide a working setup. @mgorny the Python ecosystem user experience is important to me and I’m aware there have been pains as tooling has adopted to Rust support. Gentoo particularly runs into these pains due to so much from-source building and extensive hardware support. I’m sure I’m not aware of every possible configuration, please always do feel free to ping me / direct me at things and I will do my best to help. I build PyO3 / integrate Python & Rust to empower more people to write software, not to alienate. Thank you, and I am grateful for your help whenever we run into specific problems with Rust. Unfortunately, here the problem is Rust itself — for platforms it doesn’t support, all we can do is either drop the package from that platform (which generally means also dropping all the packages that require it) or remove the Rust dependency somehow. For the latter, it often means disabling tests (which is far from optimal, but there’s at least some hope that testing on other platforms will suffice for pure Python packages), and lately replacing uv-build with a pure Python build system (say, when cachecontrol started using it, given it’s required by pip and poetry ).
ID: 277635
Author: Dima Tisnek
Created at: 2025-11-18 13:08
Number: 88
Clean content: Thank you Emma and Kirill for taking this on. The kudos you deserve is beyond what can be expressed in words. While I love reading the virtues of rust extolled… there are perhaps some areas that pre-pep should address that got glossed over. Rust’s approach to memory safety in multithreaded programs is very different from Python’s. In fact, I don’t think it can be used out of the box. Please make a plan or a PoC and show otherwise. Or set out an educated set of guards rails. Looking at the sample module, this stood out to me: #[inline]
fn encoded_output_len(input_len: usize) -> Option<usize> {
    input_len
        .checked_add(2)
        .map(|n| n / 3)
        .and_then(|blocks| blocks.checked_mul(4))
} This is just rust for the sake of rust. A safe C equivalent would be two lines long. The moral is that not all valid rust code belongs to CPython, just like PEP-7, there needs to be a spec about what rust features and idioms to use and what not to.
ID: 277637
Author: David Hewitt
Created at: 2025-11-18 13:24
Number: 89
Clean content: dimaqq: Rust’s approach to memory safety in multithreaded programs is very different from Python’s. From subinterpreters, yes I agree there are differences. From freethreaded Python, it has so far felt very similar to me (atomic datatypes, locks etc). dimaqq: This is just rust for the sake of rust. A safe C equivalent would be two lines long. This code could be written in a one liner if really wanted, I wouldn’t pick at LOC as a relevant metric. Some Rust code is more verbose than C because it encourages checking, some Rust code is less verbose because it (e.g.) handles RAII for you. #[inline]
fn encoded_output_len(input_len: usize) -> Option<usize> {
    (input_len.checked_add(2)? / 3).checked_mul(4)
}
ID: 277638
Author: David Hewitt
Created at: 2025-11-18 13:26
Number: 90
Clean content: dimaqq: The moral is that not all valid rust code belongs to CPython, just like PEP-7, there needs to be a spec about what rust features and idioms to use and what not to. clippy and rustfmt are fantastic tools (configurable) that enable a common standard of Rust to be used widely across the ecosystem with specific tailoring possible. I would think these will be great (possibly sufficient) starting points.
ID: 277643
Author: Alex Gaynor
Created at: 2025-11-18 13:56
Number: 91
Clean content: dimaqq: A safe C equivalent would be two lines long. FWIW, I’ve tried pretty hard, but I can’t find a way to write a (readable) 2-line version of this function in C that retains the overflow checking. (And any C version I do either relies on a magic sentinel like -1 for a return value or an out param, which is obviously more challenging for the caller). I think this is a good example of a dynamic with Rust: it definitely forces you to front load a lot of work. It’s more annoying for building POCs and playing with ideas. The trade-off is you get way less debugging and vulnerabilities on the back side.
ID: 277644
Author: Sergey Fedorov
Created at: 2025-11-18 14:00
Number: 92
Clean content: This is very disappointing to see rust being pushed into Python itself. That will break Python for all platforms where rust is broken, which will hit users badly, since a lot of apps rely on Python. (And will be a regression as compared to C implementation generally.) Using it optionally, like Ruby does, is fine. I honestly hope it does not become obligatory.
ID: 277645
Author: Jakub Beránek
Created at: 2025-11-18 14:07
Number: 93
Clean content: To provide some numbers on Rust’s build performance: today, I can build the whole Rust compiler (600 kLOC) plus its ~200 dependencies (a couple more hundred kLOC) on my Zen3 16 core (8C+8HT) laptop in ~50s from scratch, in release mode with optimizations, with incremental rebuilds taking 5-20s (depending on how deep I modify something in the dependency tree). While that is still slower than rebuilding CPython, especially in incremental, I don’t think that the initiative mentioned in this PEP would run into Rust build time performance issues soon, unless you somehow manage to write (or depend on) hundreds thousands of Rust code very quickly.
ID: 277648
Author: ShalokShalom
Created at: 2025-11-18 15:19
Number: 94
Clean content: Rust’s memory safety guarantees have been formally proven by the RustBelt project for code that does not use “unsafe” . There are CVE’s in safe Rust
ID: 277654
Author: Antoine Pitrou
Created at: 2025-11-18 15:42
Number: 95
Clean content: Well, there are CVEs in pure Python too, that doesn’t mean that Python and C are equivalent when it comes to avoiding security vulnerabilities.
ID: 277656
Author: Bill Janssen
Created at: 2025-11-18 16:41
Number: 96
Clean content: I think this is a great idea! So much so I finally signed onto the Discourse server to endorse it. Will follow developments with much interest.
ID: 277660
Author: Michael H
Created at: 2025-11-18 16:54
Number: 97
Clean content: No, but it does undercut the idea that the memory safety guarantees have been “formally proven” when there are longstanding known direct counterexamples. For what it’s worth, Miri does catch that issue.
ID: 277661
Author: Dustin Spicuzza
Created at: 2025-11-18 17:01
Number: 98
Clean content: Emma Smith: How should we manage dependencies? By default cargo will download dependencies which aren’t already cached locally when cargo build is invoked, but perhaps we should vendor these? Cargo has built-in support for vendoring code. We could also cargo fetch to download dependencies at any other part of the build process (such as when running configure). Currently, it is trivial to build python on a computer that isn’t connected to the internet. IMO this must continue to be the case, it’s really important to many users in restricted environments.
ID: 277663
Author: Michael H
Created at: 2025-11-18 17:20
Number: 99
Clean content: I have too many concerns about the use of Python in various bootstrapping to be in favor of this currently. I agree with the overall goal of increasing memory safety and making it easier to write code people can be confident in by default, and I like Rust for this, but I don’t see this as the right move without more supporting pieces that just aren’t there yet when considering how Python is used in the world. It seems more advantageous to focus on which modules have both C and Python implementations that would highly benefit from the guarantees afforded. This also seems to have cleaner boundaries on a technical level, and doesn’t force people to evaluate Rust adoption as an all-or-nothing roadmap to be committed to before it is proven to work within CPython’s core development, and before seeing actual impact of even that smaller transition. It’s also worth pointing out that there are options other than rust which have stronger formal guarantees than C (some more than Rust), and which don’t require a Rust toolchain. Python is already using GitHub - hacl-star/hacl-star: HACL*, a formally verified cryptographic library written in F* for various cryptography functions, and getting more from doing so than had a Rust implementation been chosen: The code for all of these algorithms is formally verified using the F* verification framework for memory safety, functional correctness, and secret independence (resistance to some types of timing side-channels). While Rust is certainly more popular than a purpose-chosen subset of F* [1] , it serves as a point that it is possible to get the level of additional compiler-enforced safety that’s desired without compromising on the existing portability of CPython. As CPython doesn’t support these unsupported triples either, Rust stabilizing user-provided JSON targets brings it to effective parity: “You’re on your own, but the build tools required have a stable way of doing it.” I also want to be crystal clear, I don’t think it’s even remotely feasible to say “Rust has to support all target triples that have ever used or ever will use python.” There’s a limited amount of maintainer bandwidth in every project, and some hardware just isn’t being developed for by the core teams. It’s niche. A probably less important issue, but one that I think hasn’t been mentioned directly [2] , is that rust and rust-analyzer both use significantly more memory than existing tooling for C. I don’t think it’s an amount likely to be a significant contribution barrier, and don’t personally count this against the proposal, but would like to make sure all known impacts are considered. Low* ↩︎ Compile times were mentioned, but there’s workflows that avoid the brunt of this. ↩︎
ID: 277666
Author: Norman Lorrain
Created at: 2025-11-18 17:37
Number: 100
Clean content: Given that Rust isn’t standardised like C and C++ (ISO/IEC 9899, ISO/IEC 14882), isn’t this premature?
ID: 277669
Author: Alex Gaynor
Created at: 2025-11-18 17:53
Number: 101
Clean content: Python is also not standardized, and yet I don’t think any of us believe it follows that it’s premature to use it . Can you expand a bit more on why you think standardization should play into this?
ID: 277671
Author: Kirill Podoprigora
Created at: 2025-11-18 17:56
Number: 102
Clean content: That’s a good question! But I guess the real question here is: what problem does standardization actually solve? Android and Linux seem to be doing just fine with Rust, even though it doesn’t have a formal standard. Here’s an article from Mara (a member of the Rust Leadership Council) that discusses this topic: https://blog.m-ou.se/rust-standard/ .
ID: 277672
Author: Stephan Sokolow
Created at: 2025-11-18 18:08
Number: 103
Clean content: The distinction is that those are implemented using I-unsound -tagged bugs in the compiler (and no comparably advanced optimizing compiler is completely free of them) and the underlying formal proof is for “if all compiler bugs are fixed”… similar to how you shouldn’t fault a language for the underlying DRAM being susceptible to Rowhammer . I don’t have the URLs on hand, but, if I remember correctly, GCC and LLVM have equivalent tags in their bug trackers. In this context, the reason some of those bugs are long-lived is twofold: The developers have determined that they’re very difficult to encounter accidentally. Neither the rustc devs nor the LLVM devs nor the GCC devs nor any developers of optimizing compilers are willing to take on “this transformation is a security boundary, fit for processing mailcious inputs”-level responsibility.
ID: 277673
Author: Stephan Sokolow
Created at: 2025-11-18 18:15
Number: 104
Clean content: Rust has multiple mechanisms for building without access to Crates.io , depending on the specific circumstances. For example: cargo fetch and cargo build --offline can be used to separate the downloading and building while otherwise using Cargo the same way. cargo vendor can be used to vendor the dependencies without losing the information that something like cargo-audit would need. The Overriding Dependencies section of the Cargo Book covers things like overriding the Crates.io repository URL to locally point a package at a different source. While I haven’t kept up on the state of the art, it’s possible to run a local mirror of Crates.io more broadly using tools like Panamax . I think that covers all the major tiers of the problem.
ID: 277674
Author: Norman Lorrain
Created at: 2025-11-18 18:16
Number: 105
Clean content: I think in terms of a tech stack, as you go further down you want to be increasingly conservative and prevent any breaking changes.  This has been the success of Windows, which for all it’s faults is quite backward compatible.  I can take code from 30 years ago and it will run.  Similarly for the Web.  I can look at archived pages from decades ago and it will display. Python is the foundation for many projects and businesses.  I trust that code I write today will run in 1 or 2 or 5 years.  10 years, less trust. Lessons learned from 2to3 transition. In turn, C is the foundation of Python.  I trust that any changes to C will not impact Python and my investment of time, etc. won’t be at risk. The core issue is trust. There is “currency” in trust.  Python has a healthy bank account of trust, and I fear it will be at risk.
ID: 277675
Author: Stephan Sokolow
Created at: 2025-11-18 18:22
Number: 106
Clean content: Generally speaking, standardization tends to come into play for one of two purposes: Re-unifying disparate implementations of a language (C, C++, ECMAScript, etc.) Making a proprietary product look more appealing to enterprise or government decision-makers (Java, .NET, Office Open XML, etc.) Given that Rust’s regression suite and v1.0 stability promise already pin the language down more thoroughly than C or C++ and that gccrs plans to follow rustc as the source of truth, I’m not sure a standard would have much benefit here. (Seriously. Look into how much about C is left implementation-defined. We generally greatly overestimate what the spec actually calls for. That’s one reason you tend to see big projects picking one or maybe two compilers per platform and coding against those. For example, the Linux kernel is written in GNU C and the ability to compile it using llvm-clang was a little bit about retiring use of features the kernel devs had decided were mistakes and overwhelmingly about teaching llvm-clang to support GNU C. …it also has its own non-standard memory model that only works because GCC is careful not to break it.)
ID: 277677
Author: Norman Lorrain
Created at: 2025-11-18 18:27
Number: 107
Clean content: See my other answer, regarding trust.  Having a standard provides some measure of trust in a technology that is a foundation of a project. I know nothing about Android, but I read that Ubuntu had a problematic release with their porting of uutils/coreutils to Rust in 25.10.  Those tools are a foundation to a Linux system. This undermines trust in Ubuntu. I’d hate for the same to happen to Python.
ID: 277678
Author: James Webber
Created at: 2025-11-18 18:28
Number: 108
Clean content: I don’t know that there is a level of standardization or certification that can satisfy every vague concern.
ID: 277679
Author: Stephan Sokolow
Created at: 2025-11-18 18:31
Number: 109
Clean content: Personally, my trust in Python was broken as soon as I saw lines in the standard library docs saying things like Deprecated since version 3.6, removed in version 3.12. (Specifically the latter half.) It’s one of the things that made me feel relieved that I’d decided to work on a Rust rewrite for any code that doesn’t need memory-safe QWidget bindings, Django’s ecosystem, or Django ORM/Alembic draft migration autogeneration in order to minimize the “It works. Don’t **** with it” vs. “Burned myself out again trying to reinvent a stronger type system in my test suite” factor.
ID: 277682
Author: Tin Tvrtković
Created at: 2025-11-18 18:38
Number: 110
Clean content: Love this effort, a strong +1 from me. I’ve been historically wary of bigger CPython contributions because I don’t know C, and don’t particularly want to know it. Rust is a completely different matter. A lot of the introduction here is aimed at Rust as a replacement for the C parts of CPython. But I think Rust could be a huge win for optimizing Python parts of CPython. “Rewrite module X in C” usually means a significant effort, both up front and on-going, maintenance-wise. Rewriting in Rust could be a completely different story, if we do this right.
ID: 277683
Author: Norman Lorrain
Created at: 2025-11-18 18:40
Number: 111
Clean content: Maybe a standardisation to the effect that code from The Rust book, 1st edition, or 2nd edition, still work with the latest Rust. (Perhaps it does).
ID: 277684
Author: Stephan Sokolow
Created at: 2025-11-18 18:44
Number: 112
Clean content: It should. See Stability as a Deliverable for a description of Rust’s “v1.0 Stability Promise”. Basically, so long as you’re not depending on a compiler bug or security hole, the only thing which should be allowed to break vN code in any later vN+M version of the Rust compiler is the occasional change to how type inference works in edge cases. …also, I almost forgot to mention this: Ubuntu’s troubles with uutils are, in my opinion and in the opinion of others, self-inflicted. The uutils devs are quite up-front that they haven’t yet achieved their goal of passing all the tests in the GNU Coreutils test suite, so Ubuntu trying to use them is similar to all the distros that made a mess by ignoring KDE’s announcement that 4.0 was meant to be a developer preview.
ID: 277685
Author: William Woodruff
Created at: 2025-11-18 18:47
Number: 113
Clean content: Norman Lorrain: The core issue is trust. There is “currency” in trust. Python has a healthy bank account of trust, and I fear it will be at risk. How should the Python community quantify this trust, given that your original metric (standardization) doesn’t apply to Python itself? Conversely: do you moderate your trust in CPython based on the presence of unstandardized, compiler-specific extensions? The last time I checked, there were a nontrivial number of GCC extensions and attributes in the codebase (other compilers go to great efforts to be compatible with these, but they’re not standard).
ID: 277686
Author: Sam James
Created at: 2025-11-18 18:47
Number: 114
Clean content: Basically, so long as you’re not depending on a compiler bug or security hole, the only thing which should be allowed to break vN code in any later vN+M version of the Rust compiler is the occasional change to how type inference works in edge cases. Use of unstable features in crates is more common than I’d like it to be still, and the promise does not apply to that. CPython should avoid any use of them. Rust for Linux currently relies on some such features, though they’re making an effort to stabilise the ones they’re relying on and not introduce more.
ID: 277687
Author: Sam James
Created at: 2025-11-18 18:49
Number: 115
Clean content: cargo fetch and cargo build --offline can be used to separate the downloading and building while otherwise using Cargo the same way. That option would require some work besides git clone which may not be desirable. It does bring up the general question of whether CPython would want to aggressively use crates (which can bring licence questions too) or not. CPython currently has a pretty small set of external dependencies.
ID: 277688
Author: Stephan Sokolow
Created at: 2025-11-18 18:55
Number: 116
Clean content: thesamesam: Use of unstable features in crates is more common than I’d like it to be still, and the promise does not apply to that. CPython should avoid any use of them. Fair point. I haven’t used nightly for anything but the occasional nightly-only tool run (eg. Miri) in at least five years, but then I don’t do kernelspace stuff and using Rust for microcontroller hobby programming is still on my TODO list. My experience has been that there isn’t much call for nightly for cargo build -ing userspace projects anymore. thesamesam: That option would require some work besides git clone which may not be desirable. It does bring up the general question of whether CPython would want to aggressively use crates (which can bring licence questions too) or not. CPython currently has a pretty small set of external dependencies. I’d imagine cargo vendor would probably be a better fit for that. Beyond that, cargo-deny is good for enforcing policy on dependencies (licenses, security advisories, etc.) and cargo-supply-chain helps to automate the process of inspecting who you’re trusting, independent of how many pieces they decided to split their project into.
ID: 277689
Author: Emma Smith
Created at: 2025-11-18 19:07
Number: 117
Clean content: I wanted to start by thanking everyone for their feedback on the proposal so far, and say that we look forward to continued discussion. After reviewing the discussion so far, we’ve decided to re-focus the (pre-)PEP to only propose the introduction of optional Rust extension modules to CPython. We hope that with experiences gained from introducing Rust for extension modules, Rust can eventually be used for working on the required modules and the interpreter core itself in the future. However, we will leave that to a future PEP when we know more and will not be proposing that as part of the current in-discussion PEP. This should address issues with bootstrapping, language portability, and churn. We’ve also been noting lots of other feedback we’ve received, but I wanted to call this one out in particular as it has been the source of a large portion of the discussion.
ID: 277691
Author: Chris Angelico
Created at: 2025-11-18 19:59
Number: 118
Clean content: William Woodruff: Conversely: do you moderate your trust in CPython based on the presence of unstandardized, compiler-specific extensions? The last time I checked, there were a nontrivial number of GCC extensions and attributes in the codebase (other compilers go to great efforts to be compatible with these, but they’re not standard). I would, but the moderation in question is relatively slight. There are two levels of trust: “Do I believe this isn’t malicious?” and “Do I believe that this is able to do what it promises?”. The compiler-specific extensions don’t significantly affect the first one (any sort of malicious implication has to be incredibly convoluted, like “the CPython devs are trying to force people to use GCC because they are trying to boost Richard Stallman’s fame and try to get him into the Guinness Book of Records” - or something equally ridiculous), though they do have an impact on the second (“in the event of a problem, do we have true options here?”). So, yes, it does impact trust, but not all THAT much. Non-standard/compiler-specific features, to me, recall the days of IE-specific features in web sites, which had the much-less-convoluted justification “Microsoft wants everyone to use IE so they have to buy Windows”. But the trust impact depends on how viable the threat is.
ID: 277692
Author: Elchanan Haas
Created at: 2025-11-18 20:20
Number: 119
Clean content: emmatyping: When should Rust be allowed in non-optional parts of CPython? I think the timeline you are laying out here is a bit too certain. I would instead propose a timeline based on the adaption of Rust within Python. In Python 3.15, ./configure will start emitting warnings if Rust is not available in the environment. Optional extension modules may start using Rust. (Same as PEP proposal) Once the Rust has enough usage within Python extensions a PEP will be created with a timeline of making Rust mandatory.
ID: 277694
Author: Emma Smith
Created at: 2025-11-18 20:32
Number: 120
Clean content: This is no longer the current plan, please see Pre-PEP: Rust for CPython - #117 by emmatyping I don’t think we should emit a warning now that these items will be entirely optional and we don’t have a plan for making Rust required. When that is proposed in a PEP, the timeline for emitting warnings and requiring Rust will be decided there.
ID: 277695
Author: Norman Lorrain
Created at: 2025-11-18 20:34
Number: 121
Clean content: I would quantify it in terms of the timeline a codebase will still run.  1,2,5,10 years. Yes, I moderate it.  I’ve been burned by changes, and I guess this is why a foundational change like moving to Rust causes concern.  Why not defer this to Python 4?
ID: 277696
Author: James Webber
Created at: 2025-11-18 20:44
Number: 122
Clean content: Because there’s no plan to ever have a Python 4.
ID: 277697
Author: William Woodruff
Created at: 2025-11-18 21:03
Number: 123
Clean content: Norman Lorrain: I would quantify it in terms of the timeline a codebase will still run. 1,2,5,10 years. Yes, I moderate it. I’ve been burned by changes, and I guess this is why a foundational change like moving to Rust causes concern. Why not defer this to Python 4? I don’t think CPython makes a hard and fast guarantee that your code will run unmodified in 1, 2, 5, or 10 years. But even if it did: the presence of Rust inside the runtime doesn’t seem material to that property, or at least is no more material to it than everything that happens on each minor release of Python 3 anyways.
ID: 277698
Author: James Webber
Created at: 2025-11-18 21:24
Number: 124
Clean content: Emma Smith: This is no longer the current plan, please see Pre-PEP: Rust for CPython - #117 by emmatyping Given that this thread reached 100+ posts in a day (!), you might want to edit the OP to make this clear. This thread is getting some broader coverage and I expect more people will be jumping in without reading the whole thing.
ID: 277713
Author: Zachary Harrold
Created at: 2025-11-18 23:28
Number: 125
Clean content: barry: I would go further and predict that this will never happen, and claim that it shouldn’t be a goal of the Rust-in-Python project. There are 10**oodles of person-years invested in the CPython core interpreter, and I just don’t see how that will ever be cost effective to rewrite, even as a Ship of Theseus . I mean, there’s already +12,777,745/-9,190,109 total changes in a project with (currently) 2,791,005 lines of text (git diffs include non-code so this count does too). Arguably, cpython has been rewritten at least 4 times now.
ID: 277714
Author: Emma Smith
Created at: 2025-11-18 23:29
Number: 126
Clean content: Good idea, I updated the OP to mention and link to the updates to the timeline section, but left the original text for posterity.
ID: 277721
Author: Filipe Laíns
Created at: 2025-11-19 02:32
Number: 127
Clean content: Hi, thank you for being willing to take on this project! The proposal overall seems great, with the proposal scope and bootstrapping story being the only potentially major issues I see. I am only gonna comment on that, as other folks are already addressing remaining concerns. This discussion is already big as-is, and I have no doubt it will still grow much larger Proposal scope Unless I am misinterpreting it, the proposal foreword seems to imply that this is a phased proposal that will eventually add Rust as a required build dependency of CPython, but the presented PEP only covers making it an optional build dependency. This proposal declares Rust will at some point will stop being optional. While I understand the motivation, I feel like deciding this right now is too early. I don’t think the PEP provides strong enough supporting evidence to outweigh the potential implications of such a major change. The downstream impact is still pretty up in the air, as is the impact on development, etc., while the potential benefit of introducing Rust into the core code-base is still very unclear. When I say the benefit of using Rust in core is unclear, I am not questioning Rust’s benefit over C. It’s the quantity of opportunities where it would make sense to use it that is unclear. I strongly believe we should not be rewriting existing code in Rust without a specific reason, and that’s what I think is unclear at this point. Even the PEP is unsure of the timeline for promoting Rust to a hard build dependency, probably because of this. I think this proposal would be much easier to drive forward if it were split into two phases, each with its own PEP. Introducing Rust as an optional build dependency Promoting Rust to a hard build dependency This way, 1) would allow us to gather feedback from the development team, downstreams, etc., giving us a much better picture of the impact of 2), enabling us to make a better argument and design a more concrete plan. With this in mind, here are my suggestions for the PEP text: Add an “Abstract“ section explaining that the PEP is a first step into the adoption of Rust in the CPython codebase, introducing it in an optional capacity, allowing us to experiment, gather developer feedback, and better assess the technical implications of using Rust in CPython. Add a “Goals“ section Explicitly state that rewriting existing code in Rust without further motivation is a non-goal Define a couple of goals, like the following Evaluate how well the development team engages with Rust inside the codebase Evaluate how well the CPython architecture couples with Rust Evaluate the impact of first-party Rust APIs on downstream users (eg. PyO3) Gather feedback from downstream users regarding the bootstrapping implications Gather feedback from downstream users of platforms where Rust is not supported Add a “Future“ section explaining that, contingent on the impact of this PEP, we plan to promote Rust to a hard build dependency as a next step Remove “Keep Rust Always-Optional“ from “Rejected Ideas” TLDR I don’t feel the PEP provides enough justification to make Rust a hard build dependency, and I think that’s something that would be difficult to provide at this point. As such, I feel like this proposal would be better served by splitting into two phases/PEP — starting with adding Rust as an optional build dependency, and then promoting it into a hard build dependency. Bootstrapping I personally don’t think any of the given solutions are good enough at the moment, so it is very important to explore other options. IMO, even if no better solutions are found, the PEP authors should show they have exhausted all other sensible possibilities. That said, I may be mistaken, but it’s my understanding that Python should only be needed to build LLVM for rustc . Perhaps it would be worth exploring the possibility of using the Cranelift backend instead, which AFAICT doesn’t need Python. It may also be worthwhile to engage with the mrustc project, as they may have better insights on other possible approaches. Another thing that I thought it would be pertinent to point out. If we were to introduce Python to the bootstrapping dependency tree (via Rust), that would greatly weaken the argument against moving CPython’s build system to Meson (discussion in What do you want to see in tomorrow’s CPython build system? ).
ID: 277722
Author: James Webber
Created at: 2025-11-19 02:34
Number: 128
Clean content: Filipe Laíns: I don’t feel the PEP provides enough justification to make Rust a hard build dependency, and I think that’s something that would be difficult to provide at this point. Good news, this was agreed upon somewhere in the next 100ish posts of the thread.
ID: 277725
Author: Stephan Sokolow
Created at: 2025-11-19 04:03
Number: 129
Clean content: I claim that one of the major reasons for this failure is that cargo is almost unique among build systems in providing absolutely no structured mechanisms for: (1) communicating with other package build scripts in the same dependency graph (2) communicating with the downstream user who invokes cargo (such as a distro packager, or a github actions pipeline) An update on work in this direction: The GSoC results page details progress on Prototype Cargo Plumbing Commands . Not what you asked for, but evidence of how this sort of thing is on the radar.
ID: 277731
Author: Alyssa Coghlan
Created at: 2025-11-19 06:59
Number: 130
Clean content: I’ll chime in with a +1 on the idea of allowing Rust extension modules, -1 (at least for now) for the core interpreter and compiler (which is already the direction the descoped PEP has moved in). For the core interpreter (at least the part which needs to be built in order for CPython to freeze its own frozen standard library modules), I think the bootstrapping and long tail platform support concerns are significant enough to at least postpone consideration of the possibility, and potentially even enough to block it forever. For extension modules manipulating untrusted input data, I see huge potential value in having access to Rust as a fast low overhead statically typed language with rich data structures and implicitly thread local data access. (For a concrete example of that from nearly 10 years ago, here’s a Sentry post about migrating their JavaScript source map processing from Python to Rust , and the benefits of not incurring the per-instance overhead of creating full Python objects). There are some cases where platform compatibility may still be a concern, but extension modules will have more options for handling that than the core interpreter does.
ID: 277732
Author: Dima Tisnek
Created at: 2025-11-19 07:09
Number: 131
Clean content: alex_Gaynor: dimaqq: A safe C equivalent would be two lines long. FWIW, I’ve tried pretty hard, but I can’t find a way to write a (readable) 2-line version of this function in C that retains the overflow checking. My take: if (len > PRECOMPUTED_CONST) return -1;
return (len + 2) / 3 * 4; My point was exactly about the fact that crustaceans worry about overflow checking, borrow safety, traits, etc., and write verbose code that is beautiful, while pragmatic folk reduce the problem, put safety limits leaving the implementation very short. After all, what’s the point of encoding a string that’s larger than a fraction of the total address space? The Rust overflow checker is only effective at ~3/4 RAM, at which point the argument and result cannot fit into RAM at the same time. Fancy Rust safety is totally appropriate for user-defined or external input (e.g. networking code, cryptography or json.dumps argument where some inner dict-like object may have a custom dunder method that does some “caching” but ends up modifying sibling elements in flight or creates cycles), while simple concepts should in my opinion remain simple, so that the code remains maintainable, ideally also by contributors who are not Rust experts. Which is why I’m calling for the equivalent of PEP-7 for Rust use in CPython. ShalokShalom: Rust’s memory safety guarantees have been formally proven by the RustBelt project for code that does not use “unsafe” . There are CVE’s in safe Rust I’d go even further and decry “proven safe” as smoke and mirrors. Remember the BAN logic proof for the Needham–Schroeder protocol? To recap, every proof is against a certain fixed set of assumptions. Meanwhile what happens in practice is that software is reused in ways unpredictable a priori. RustBelt has proven something about Rust, but not about Rust use in CPython, or Rust use in 3rd party Python extensions and certainly not about Rust used within CPython when an arbitrary user program is run by the interpreter, with arbitrary additional extension, for arbitrary goals and with arbitrary thread model. Here my call is to move most of Rust exultations into the footnotes, and focus on tangible direct benefits instead: safer refactoring / faster reviews, broader contributor pool / potentially more approachable to new contributors who grew up with safe/typed languages, specific CPython core bug classes (not generic C bugs), cleaner (more self-documented) internal APIs, safer norms for 3rd party extensions, possibly safer/faster backport story, potentially better tooling, possibly CPython guts (e.g. regexp) shared as crates for other uses…
ID: 277734
Author: Emma Smith
Created at: 2025-11-19 07:32
Number: 132
Clean content: Dima Tisnek: Which is why I’m calling for the equivalent of PEP-7 for Rust use in CPython. This is definitely something I hope to work on with folks. We will need a standard style for Rust in CPython, but I also think that might depend as we adopt Rust and expand the current proof of concept. Regardless it probably should be it’s own PEP, in my mind drafted and published after this one is approved. Dima Tisnek: RustBelt has proven something about Rust, but not about Rust use in CPython That’s certainly true, but in projects that have adopted Rust for a while, we see significant decreases in memory safety bugs. Here’s an excerpt from a blog about Rust adoption in Android: We adopted Rust for its security and are seeing a 1000x reduction in memory safety vulnerability density compared to Android’s C and C++ code . But the biggest surprise was Rust’s impact on software delivery. With Rust changes having a 4x lower rollback rate and spending 25% less time in code review Our historical data for C and C++ shows a density of closer to 1,000 memory safety vulnerabilities per MLOC. Our Rust code is currently tracking at a density orders of magnitude lower: a more than 1000x reduction. From Google Online Security Blog: Rust in Android: move fast and fix things I agree with you that it is important to highlight that Rust can increase developer velocity as well as provide memory safety. I think this is something we will highlight more in the PEP draft and is something a few people have mentioned. Here’s another excerpt from the above blog related to that: For medium and large changes, the rollback rate of Rust changes in Android is ~4x lower than C++. Rust changes currently spend about 25% less time in code review compared to C++. These are definitely things we will be focusing on more in the PEP text itself.
ID: 277740
Author: Stephan Sokolow
Created at: 2025-11-19 08:50
Number: 133
Clean content: dimaqq: To recap, every proof is against a certain fixed set of assumptions. Meanwhile what happens in practice is that software is reused in ways unpredictable a priori. RustBelt has proven something about Rust, but not about Rust use in CPython, or Rust use in 3rd party Python extensions and certainly not about Rust used within CPython when an arbitrary user program is run by the interpreter, with arbitrary additional extension, for arbitrary goals and with arbitrary thread model. While I agree that focus should be on other benefits (eg. I spent a decade in /r/rust/ and people coming from C++ loved the tooling most), I think it goes too far to call “proven safe” smoke and mirrors. That stance generalizes far too easily to things like “It’s a waste of time to make Python memory safe because import ctypes exists”, which makes it far too easy for people to dismiss… especially when the whole point of things like the safe/unsafe split and the way parts of Rust have been formally verified is to draw boxes around bits of code and say “assuming no external factor, such as bad RAM or abuse of unsafe violates the invariants, this code’s behaviour will meet expectations”.
ID: 277741
Author: Ricardo Robles
Created at: 2025-11-19 08:53
Number: 134
Clean content: I’m not a Rust expert; I only have work experience with C/C++ and Python. What advantages would Rust have over other languages ​​like Go? I’m just asking to understand Rust’s advantages and to make sure it’s for a real reason and not just to “Rustify” everything.
ID: 277742
Author: Stephan Sokolow
Created at: 2025-11-19 08:55
Number: 135
Clean content: Go depends on having a garbage collector and garbage collectors are solitary creatures, which makes it unsuitable for writing extensions or rewriting components of a C or C++ codebase. (That’s one reason Jython and IronPython exist, instead of integrating CPython with the JVM and CLR. They live within the JVM or CLR’s existing GC instead of competing with it.) Rust is noteworthy because it’s the only language to gain significant traction in this niche previously held almost exclusively by C and C++. EDIT: To elaborate on that, Rust enables compile-time guarantees that C and C++ are incapable of without relying on a heavy VM to do it. That’s what makes it essentially unique. (Though other languages like D and Ada are starting to copy Rust’s innovations.)
ID: 277746
Author: Miraculixx
Created at: 2025-11-19 09:06
Number: 136
Clean content: Not a core dev, yet experienced in large scale sw development including changing of core tech. Spoiler alert: these efforts usually fail. I always recommend to answer three key questions before embarking on changing foundational pieces of the stack: Is the new stack introduced for its coolness instead of solving an actual problem? Will the new stack introduce new problems that the old stack does not have? Does the investment in time and effort to introduce the new stack compete with more worthwile work that delivers value to users? If the answer to any of these questions is yes, and the change is pressed on anyway, the outcome will eventually land in one of two states: Efforts will stall and the resulting two-stack system is more complex than ever before, effectively meaning the change will be consuming ever more resources to no good cause. The complexities introduced by the new stack have a far higher blast radius than previously anticipated, triggering a complete rewrite, eventually reaching feature parity with no added value. In short, I recommend to avoid the introduction of Rust as an alternative to C in CPython(!).
ID: 277749
Author: Kirill Podoprigora
Created at: 2025-11-19 09:34
Number: 137
Clean content: Miraculixx: Not a core dev, yet experienced in large scale sw development including changing of core tech. Spoiler alert: these efforts usually fail. We’ve received a lot of messages from people who want to help, and even members of the Rust core team are willing to support us. As we mentioned earlier, there are two strong examples of Rust adoption done right: Rust for Linux and Rust for Android. Here’s the blog post from the Android team: Google Online Security Blog: Rust in Android: move fast and fix things We’re fully committed to putting a lot of effort into this initiative, and to making sure we don’t fail Miraculixx: Is the new stack introduced for its coolness instead of solving an actual problem? We’re addressing a real problem: CPython like many other projects written in C or C++ suffers from memory-safety vulnerabilities. Rust can drastically reduce the number of these vulnerabilities. From the Android blog post: We adopted Rust for its security and are seeing a 1000x reduction in memory safety vulnerability density compared to Android’s C and C++ code . Miraculixx: Will the new stack introduce new problems that the old stack does not have? I’m pretty sure this project will encounter at least one challenge: CPython contributors who don’t know Rust will need to dedicate some time if they want to contribute to the Rust parts. Other challenges will only become clear as we move forward, and that’s where members of the Rust core team may be able to help us. As I understand it, they supported the Rust for Linux project as well. Miraculixx: Does the investment in time and effort to introduce the new stack compete with more worthwile work that delivers value to users? Sorry, but I’m reading that part of your message as if this were about business. CPython is an open-source project, and most of us volunteer our time for free. Because we’re volunteers, we’re free to choose whichever problems we want to work on. So, we chose this problem and here’s the solution we believe in: Rust . Miraculixx: Efforts will stall and the resulting two-stack system is more complex than ever before, effectively meaning the change will be consuming ever more resources to no good cause. The complexities introduced by the new stack have a far higher blast radius than previously anticipated, triggering a complete rewrite, eventually reaching feature parity with no added value. I’d like to quote Android blog again: But the biggest surprise was Rust’s impact on software delivery. With Rust changes having a 4x lower rollback rate and spending 25% less time in code review , the safer path is now also the faster one.
ID: 277752
Author: Miraculixx
Created at: 2025-11-19 09:52
Number: 138
Clean content: Eclips4: We’re fully committed to putting a lot of effort into this initiative, and to making sure we don’t fail Said every team ever. I don’t doubt that. Just for reference, can you point to some of the memory saftey issues that would have been avoided if CPython were using Rust?
ID: 277758
Author: Zander
Created at: 2025-11-19 10:08
Number: 139
Clean content: It is undeniable that Rust offers superior safety over C and can effectively prevent many errors that would otherwise occur. However, introducing Rust into CPython may inevitably lead to some divergence within the community, with some developers in favor and others potentially having reservations. Additionally, this would require developers to be proficient in C, Rust to effectively address related issues. More importantly, as the proportion of Rust code in the project gradually increases, there may be growing calls within the community for a full transition of CPython to Rust. This could further intensify disagreements among core developers, somewhat reminiscent of certain situations the Linux community has experienced in the past. If all proceeds smoothly, we might eventually achieve a RustPython that remains compatible with the C ABI. That said, RustPython already exists today, though it still lags behind CPython in terms of features and ecosystem. Wouldn’t steadily improving it be a more feasible path forward? This approach may prove more manageable than integrating Rust directly into CPython. If there is a clear advantage to introducing Rust into CPython, it may lie in the ability to gradually migrate the official Python implementation from C to Rust while preserving existing functionality and compatibility. If the current path is maintained, CPython will continue to be implemented in C, and even if RustPython develops remarkably, replacing the official implementation would present significant challenges—since doing so would likely require the current maintenance team to undergo a major transition.
ID: 277762
Author: Kirill Podoprigora
Created at: 2025-11-19 10:12
Number: 140
Clean content: gh-133767: Fix use-after-free in the unicode-escape decoder with an error handler by serhiy-storchaka · Pull Request #129648 · python/cpython · GitHub and many other UAFs
ID: 277764
Author: Stephan Sokolow
Created at: 2025-11-19 10:53
Number: 141
Clean content: Zander-1024: If all proceeds smoothly, we might eventually achieve a RustPython that remains compatible with the C ABI. That said, RustPython already exists today, though it still lags behind CPython in terms of features and ecosystem. Wouldn’t steadily improving it be a more feasible path forward? This approach may prove more manageable than integrating Rust directly into CPython. Whenever I see arguments like this, I get the impression that the people making such an argument forget what “volunteer” means. If they’re not getting paid to work on Python, then it’s entirely possible that it’s not “Rust vs. C”, but “Rust vs. wear out and stop contributing”. I know that situation is why I’m rewriting my Python projects in Rust. Even without memory safety on the line and even with strict-mode MyPy, the constant vigilance of a dynamic language with ubiquitous NULL/None/nil and exceptions introducing hidden return paths all over the place wears on me.
ID: 277785
Author: Jacopo Abramo
Created at: 2025-11-19 15:17
Number: 142
Clean content: I don’t want to bring fuel to the fire as I’m just observing the decision making process, but the timing of the situation was just too funny for me. Apparently in September Cloudflare migrated some internal library to Rust … … and after investigation, the recent November outage was effectively caused by some code that wasn’t appropriately managing memory in this new library. But at any rate the pre-PEP has already been discussed exhaustively, it was just my sense of humour that found this hilarious in the context of this discussion where lots of points about integrating Rust were about memory safety.
ID: 277790
Author: Paul Moore
Created at: 2025-11-19 15:43
Number: 143
Clean content: Stephan Sokolow: If they’re not getting paid to work on Python, then it’s entirely possible that it’s not “Rust vs. C”, but “Rust vs. wear out and stop contributing”. This is a good point that doesn’t seem to be getting enough attention. I can’t speak for any of the core devs that routinely work on the C parts of the codebase, but I can say that personally, there were a number of improvements that I would have loved to make to the old py launcher, which I gave up on because I couldn’t face the manual memory management, and pointer manipulation, involved in string processing in C. If the launcher had been written in Rust [1] , then I could have used Rust’s standard string type, and as a result I would have been motivated to work on those improvements. So yes, a significant benefit of using Rust, even just for isolated parts of the Python stdlib, is that it could dramatically reduce the risk of developer burnout. Of course, we have to take care not to have the transition process burn people out as well, but I’m in favour of doing extra work to manage a short-term transition exercise in order to set up a better long term foundation. An entirely reasonable possibility, it was self contained, and its build process is isolated from the core build. ↩︎
ID: 277807
Author: Roman Vlasenko
Created at: 2025-11-19 17:20
Number: 144
Clean content: jacopoabramo: it was just my sense of humour that found this hilarious in the context of this discussion where lots of points about integrating Rust were about memory safety. I’d say that this is misleading. The Cloudflare’s outage actually has nothing to do with the memory safety guarantees of Rust or with inappropriately managing memory in general.
ID: 277808
Author: Davide Rizzo
Created at: 2025-11-19 17:27
Number: 145
Clean content: I’m a huge fan of this proposal. Thanks everyone for the effort. I volunteer to support in the endeavor in any way needed. The technical details can be discussed in due time, but one thing I’d love is for CPython API to define things around ownership and thread safety more formally. Right now this is delegated to documentation, but both C users and foreign language binding implementers (e.g. Rust and C++) would benefit if they could verify that a certain reference is meant to be owned or borrowed and so on. I understand there are challenges on both the technical and social aspect. I wish for both the aspects to be cared for seriously (and I renew my availability for help). It’s not the first time that adoption of Rust in a big project brings up some strong [1] resistance. I feel that there is space to adequately understand needs and worries; and to empower the people who have some stake in this change to impact the process. For example, some people brought up a worry that Rust is chosen because it’s a trendy toy rather than an actual solution. It’s good to spend time identifying why this is considered a problem, why it is a worry, and what can be done to address it. In part this is being done now (thanks to everyone who took time to answer) by reassuring that there is technical merit and proper research into the solution. But maybe this is not the whole argument and people would like to hear something closer to their worry. In other contexts I’ve seen a resistance to Rust adoption as a sort of threat to job stability (growing as a proficient C programmer takes a huge investment and attention to a number of issues, and something like Rust seems to promise to automate away part of your skill set), and maybe that also needs to be treated with care and empathy. And, on the other side, people wanting to see Rust introduced have their needs (that might not be entirely obvious besides the technical value) and might be faced with walls and gatekeeping and, as it happened in other projects, could be discouraged or burn out when they don’t see those needs understood, or their good will acknowledged. So, please, let’s not disregard that this is a socially loaded topic, and people are already reacting in many ways. I hope that the discussion will be smooth but I will not bet on it. and, sometimes, unexpectedly violent or vicious. Fortunately nothing of that sort is visible on this thread. ↩︎
ID: 277812
Author: Stephan Sokolow
Created at: 2025-11-19 18:58
Number: 146
Clean content: To elaborate on “nothing to do with […] Rust”, the outage was down to: We wrote a recipient service which preallocates memory as an optimization. Since we wrote it to ingest data from one of our other services, we made the assumption the data would always be well formed and had it preallocate 3⅓ times as much space as we’re currently using. We committed a bug to the sender service which caused it to produce data bundles that blew past that 3⅓ times safety margin. It’s a logic bug. If they’d written it in C or C++ it would have been an ASSERT or SIGSEGV and, in Rust, it was doing the equivalent of dying with an uncaught AssertionError . (Basically, a violation of “Assume ‘unreachable’ never is”.)
ID: 277835
Author: Emma Smith
Created at: 2025-11-19 22:33
Number: 147
Clean content: Davide Rizzo: I volunteer to support in the endeavor in any way needed. Excellent! Thank you! Davide Rizzo: The technical details can be discussed in due time, but one thing I’d love is for CPython API to define things around ownership and thread safety more formally. Right now this is delegated to documentation, but both C users and foreign language binding implementers (e.g. Rust and C++) would benefit if they could verify that a certain reference is meant to be owned or borrowed and so on. I think that in Linux they have seen a number of improvements by better defining the ownership of various parts of the kernel, so this would be very nice. I think it may be a while before it is feasible, but we shall see! Davide Rizzo: So, please, let’s not disregard that this is a socially loaded topic, and people are already reacting in many ways. I hope that the discussion will be smooth but I will not bet on it. Very important to remember! Going into working on this proposal I was trying to be very cognizant that this topic can engender strong feelings. I think overall I have been pleased with how the discussions have gone so far. I think so far folks have demonstrated that they can engage on this topic in a level-headed and cordial manner. I hope that trend continues. I also hope it has been clear in my own communications that I hope to understand and care about the the views of people who may disagree with the proposal. I do not want to drive away current contributors. I will also re-iterate that if anyone would like to chat about concerns regarding the proposal not in a discussion thread, please feel free to DM me!
ID: 277845
Author: Emma Smith
Created at: 2025-11-19 23:53
Number: 148
Clean content: Zander: RustPython already exists today, though it still lags behind CPython in terms of features and ecosystem. Wouldn’t steadily improving it be a more feasible path forward? I don’t think so for a couple of reasons. First, RustPython are semantically different enough that I think merging the semantics would be a significant undertaking: Jeong, YunWon: RustPython isn’t something that can be considered in this PEP in short term. RustPython and CPython are not semantically compatible across many layers of their implementation. Jeong, YunWon: RustPython has its own approach to running without a GIL, but it’s not compatible with CPython’s nogil direction. Second, introducing Rust to CPython would see direct benefits to the millions of users CPython has today. Improving RustPython might see benefits to it’s current user base, but to get current CPython users to switch would need to be earned through proven compatibility over a long time period. That sounds like much more of an uphill battle with unclear benefits.
ID: 277847
Author: Brett Cannon
Created at: 2025-11-20 00:22
Number: 149
Clean content: Alyssa Coghlan: long tail platform support concerns FYI Git 2.52 now optionally uses Rust and it will be required in Git 3 . Zander: introducing Rust into CPython may inevitably lead to some divergence within the community Divergence how? The key people who would be affected by this are: Core developers People who build CPython from source But as has already been stated, the PEP will have Rust usage be optional, so really, the people who will be affected by the planned PEP are: Core developers And so far I have seen more +1 than -1 from core developers. Paul Moore: If the launcher had been written in Rust GitHub - brettcannon/python-launcher: Python launcher for Unix (although admittedly I’m now curious to see if Python performance is such that I can just do it in pure Python and package it up appropriately).
ID: 277849
Author: H. Vetinari
Created at: 2025-11-20 00:58
Number: 150
Clean content: Emma Smith: I think that in Linux they have seen a number of improvements by better defining the ownership of various parts of the kernel, so this would be very nice. This is one of the points that Greg KH [1] explicitly calls out repeatedly as a benefit of the Rust-for-Linux effort, even if Rust went away again (here’s a recent talk with a timestamped link ): By forcing the C APIs to define their semantics, the C APIs themselves often were improved. one of the most veteran Linux contributors, maintainer of LTS kernels and involved in every security issue ↩︎
ID: 277874
Author: GalaxySnail
Created at: 2025-11-20 04:51
Number: 151
Clean content: Brett Cannon: FYI Git 2.52 now optionally uses Rust and it will be required in Git 3 . Git 2 → Git 3 sounds like Python 3 → Python 4. Git isn’t a programming language, you only need an implementation of Git’s wire protocol to interoperate with others, don’t even need to keep the on-disk format compatible. I don’t think Git’s choice necessarily tells us what we should do for CPython. Since the authors of this pre-PEP have already decided to make Rust optional for CPython, there isn’t much more to discuss about making Rust required.
ID: 277875
Author: Stephan Sokolow
Created at: 2025-11-20 05:10
Number: 152
Clean content: Git 3 is bringing in support for SHA256 commit hashes, which is a protocol break. (From what I remember, Rust is used to write the part which allows seamless SHA1 → SHA256 transitioning within a repo.)
ID: 277888
Author: Da Woods
Created at: 2025-11-20 07:02
Number: 153
Clean content: Question related to RustPython: they look to have made good progress on compatibility but not great progress on performance so far. Is there anything to be learned from why? I.e. if it’s just lack of time and contributors then it probably isn’t very interesting to this discussion, but if they were finding some optimisations difficult in Rust it might be useful to know.
ID: 277894
Author: Jeong, YunWon
Created at: 2025-11-20 08:17
Number: 154
Clean content: da-woods: Question related to RustPython: they look to have made good progress on compatibility but not great progress on performance so far. Is there anything to be learned from why? 2 main reasons, which are mirror-side of each other. First, the core language part of CPython is very well optimized. RustPython adopt a few parts of them, but not able to finish major parts of them. Second, RustPython contributors (like me) didn’t have enough interests on the performance. So it happened just occasionally. So… that’s not by technical issues. Just lack of driving to the performance. If anyone interested in enhancing performance of RustPython, I will do my best support.
ID: 277898
Author: Jeong, YunWon
Created at: 2025-11-20 08:27
Number: 155
Clean content: emmatyping: Interactions between Python objects and borrows is rather complicated. I don’t think this thread is a great place to go over detailed API design discussion as that isn’t the goal of the PEP, but I’d be happy to chat in another forum like the Python Discord or via DM. I will say a pie-in-the-sky API will look somewhat like an implementation using PyO3 . A sample clone in RustPython; it is not PyO3 though. The technical details will differ, but once Rust for CPython gains sufficient abstraction, it will reach a similar level in terms of cognitive load. github.com/youknowone/RustPython _base64 main ← _base64 opened 08:08AM - 20 Nov 25 UTC youknowone +87 -0 ## Summary by CodeRabbit

* **New Features**
  * Base64 encoding support is now … available in the standard library. Users can encode binary data into standard Base64 format with built-in error handling and safety guarantees for large datasets. This enables reliable and efficient data transformation for applications requiring text-safe data representation and enhanced cross-platform system compatibility.

<sub>✏️ Tip: You can customize this high-level summary in your review settings.</sub>
ID: 277904
Author: Mark Shannon
Created at: 2025-11-20 09:58
Number: 156
Clean content: Personally, I think this makes a lot of sense for extension modules and some components, but not so much for the core of the VM (the interpreter, gc, and core objects). The safety, or lack of safety, of those components depends not so much on the language they are written in, but the design. If you feed dodgy bytecode to the interpreter it should crash, or worse. That’s how it is supposed to work. What is the proposed API for rust? The section on implementation talks about using bindgen, but what is the underlying C API that you are binding? The limited API or the warts-and-all “unlimited” API? You mention PY_OBJECT_HEAD_INIT but that just couples rust code to the deep internals of the VM. If we are introducing a new API, then it should be a good one. It should follow the design on HPy , or its successor PyNI . The linear typing of HPy handles should work very well with rust’s ownership model.
ID: 277922
Author: Steve Dower
Created at: 2025-11-20 14:53
Number: 157
Clean content: H. Vetinari: By forcing the C APIs to define their semantics, the C APIs themselves often were improved. Yes, I think this is the best we can look forward to if the plan to progressively replace the core runtime implementation with Rust were still on the cards (which I assume it is, just unofficially for now - it doesn’t make any sense at all to “put Rust in CPython” without that ambition, since you can already write an extension module using Rust without our permission [1] ). And we are already working to improve the semantics of our C APIs as quickly as we can without destroying our existing user base - adding Rust won’t help here (it’ll let us get away with more breakage for some people “because Rust”, but it’ll upset other people who still want minimal breakage, and on average I expect it’ll make no real difference). What the current proposal comes down to is “can we make some stdlib extension modules optional for some people”, where the answer is obviously “yes” as we already make a number of them optional for users who don’t have/support/want certain third-party libraries. So the slightly higher-level question is “are we willing to make some modules optional based on compiler choice, rather than based on access to the core functionality required by the module”. (For example, if I don’t want/have OpenSSL, then the _ssl module is obviously useless and best omitted. But if I don’t want/have Rust, why should I miss out on _base64 ?) That question is the real, practical impact that we have to decide on. Everything else is hypothetical and achievable in this way or in other ways. But if we’re not willing to have a more inconsistent stdlib across our userbase, then the overall question seems to be moot, at least until Rust can be assumed to be as available as make+GCC. I’ll also note here that the SC has previously approved putting obviously core functionality on PyPI (subinterpreters), so until we rotate through to an entirely new SC, I don’t think there’s a case for “has to be in core” other than taking advantage of our popularity (which has been earned through stability, so we shouldn’t ruin it by actively destabilising it). ↩︎
ID: 277923
Author: James Webber
Created at: 2025-11-20 15:05
Number: 158
Clean content: Steve Dower: (which I assume it is, just unofficially for now - it doesn’t make any sense at all to “put Rust in CPython” without that ambition, since you can already write an extension module using Rust without our permission ). While I think some view that as an end goal, a PEP to allow Rust extensions in the stdlib still stands on its own merit–there should be a formal decision whether to allow that expansion. Even if the ultimate goal was “let some optional extensions be Rust” it would still need a PEP, no?
ID: 277924
Author: Jelle Zijlstra
Created at: 2025-11-20 15:05
Number: 159
Clean content: I like the idea of moving CPython towards Rust, but I feel the current proposal is so conservative that it doesn’t really get us there. The idea is to allow optional extension modules to be written in Rust. That basically means either new accelerators for modules currently written in Python, or completely new stdlib modules (which are rare). They have to be optional, which means that we must also maintain a Python (or C!) version, at least for existing modules. The concrete suggestion is base64 , which is currently fully in Python. The “optional” part means that this proposal will make the stdlib more inconsistent across users. There are many ways the stdlib is already inconsistent in this way, but I feel that’s generally a bad situation that we should avoid making worse: ideally, Python should be the same for all users, and users who use base64 shouldn’t have to think about the details of their platform to know its performance characteristics. There might be another unfortunate consequence. Clearly, lots of people are very excited about getting Rust in CPython. But with this proposal, the only realistic way they can do that is by adding new accelerator modules. Those could be for modules that already have a C accelerator, but in that case we have to keep the C version too to avoid creating a regression for users without Rust. Or it could be for modules that are currently fully in Python. But I’m not sure how many such modules there are for which an accelerator really makes sense: in most cases, if we’d wanted a C accelerator, we’d have written one already. Therefore, we might end up with Rust code that is mostly replacing Python code, not C code, and that isn’t terribly high-impact. To get safety wins from using Rust, we have to stop using C. Not necessarily everywhere, definitely not everywhere immediately, but at least somewhere. So for this proposal to be accepted, I feel there must be a clear path towards making it possible to replace existing C code with Rust, even if that means making Rust required.
ID: 277926
Author: Antoine Pitrou
Created at: 2025-11-20 15:17
Number: 160
Clean content: Jelle Zijlstra: So for this proposal to be accepted, I feel there must be a clear path towards making it possible to replace existing C code with Rust, even if that means making Rust required. IMHO that “clear path” must be conditioned on the bootstrap issues being solved. As in: bootstrapping CPython-with-Rust should not be harder than bootstrapping CPython-without-Rust. Once that happens, them I’m fully +1 for Rust in CPython, including core parts.
ID: 277927
Author: Steve Dower
Created at: 2025-11-20 15:17
Number: 161
Clean content: James Webber: While I think some view that as an end goal, a PEP to allow Rust extensions in the stdlib still stands on its own merit–there should be a formal decision whether to allow that expansion. Sure, but as I said in the rest of my post, that “formal decision” is really “can we let some people be lacking certain stdlib modules”. The choice of language is fairly orthogonal, since it isn’t going to affect the design of the runtime at all - we might as well bundle up C++ extension modules in the same PEP, since a similar number of users will be unable to use those, and some extension modules would benefit. Also, there’s only a small gap between “the stdlib may not have this module for you” and “if you want this module, choose to add it”. The latter is already possible with whatever language you want to use, so with the re-scoped proposal, we’re only slightly reframing things from the latter to the former. Once we’re officially okay with “the library is (core modules) plus (optional modules) plus (whatever your distro adds) plus (whatever you’ve installed)”, [1] then “optional modules” could be anything from anywhere (which means it’s really easy to say “yes, they could use Rust”). For explicitness, the current situation is “the library is (core modules) plus (whatever your distro adds) plus (whatever you’ve installed)”. The only thing we’re adding here is “optional modules”. ↩︎
ID: 277929
Author: Antoine Pitrou
Created at: 2025-11-20 15:25
Number: 162
Clean content: Steve Dower: we might as well bundle up C++ extension modules in the same PEP, since a similar number of users will be unable to use those, and some extension modules would benefit. I don’t think it would be the case. Everywhere you have a C compiler, you probably have a C++ compiler too.
ID: 277930
Author: Steve Dower
Created at: 2025-11-20 15:26
Number: 163
Clean content: Antoine Pitrou: I don’t think it would be the case. Everywhere you have a C compiler, you probably have a C++ compiler too. I agree, but I’m trying to be generous here We already have an (optional) C++ extension module in the stdlib, but don’t tell anyone.
ID: 277931
Author: Kirill Podoprigora
Created at: 2025-11-20 15:49
Number: 164
Clean content: Jelle Zijlstra: The concrete suggestion is base64 , which is currently fully in Python. In fact, base64 is built on top of the binascii module, which is implemented entirely in C. So I think you’re right, we can try replacing the current binascii implementation with a Rust-based one.
ID: 277935
Author: Xie Qi
Created at: 2025-11-20 16:34
Number: 165
Clean content: This post is about Rust, so it will attract considerable attention from Rust fans. As a result, most of the comments are likely to be positive (since they come from Rust fans). We still need to wait and see. but eventually will become a required dependency of CPython and allowed to be used throughout the CPython code base <del> Additionally, using Rust (which relies on LLVM) means abandoning many niche platforms.  Is this really an appropriate choice? Many popular open-source projects use Python to some extent.  If CPython drops support for certain platforms, those platforms will no longer be able to run many projects that depend on Python. That would be truly unfortunate! Rust may mitigate some memory-related issues, but… are you really in such a hurry to introduce Rust into CPython? In any case, Rust should be made optional. This way, maintainers of (Python-dependent) open-source projects can choose whether to use the Rust-dependent features or not. They deserve to have a choice! Moreover, making Rust a mandatory dependency for CPython sounds like a proposal driven by Rust fans to push their own agenda. </dev> Perhaps we can wait until the maturity of the following options: C++26: hardening and contract Zig gcc-rs After that, we can conduct more comparisons before making a final decision.
ID: 277939
Author: Filipe Laíns
Created at: 2025-11-20 16:52
Number: 166
Clean content: Thanks for pointing that out, that’s a great point. Personally, I thought of optionally introducing Rust more as a way to better understand how it would affect the community, and how well it would fit into the CPython codebase, and developers’ workflows. I also don’t see a great value from allowing Rust in optional modules purely from a maintainer perspective, but I think it is a necessary step to decide on making Rust a hard build dependency. That said, maybe someone else does have a use-case where Rust being available for optional components would be great. If that’s the case, it would be great to let us know
ID: 277955
Author: Stephan Sokolow
Created at: 2025-11-20 19:19
Number: 167
Clean content: shynur: Perhaps we can wait until the maturity of the following options: C++26: hardening and contract Zig gcc-rs Bear in mind that Zig isn’t aiming to serve the same niche as Rust as far as safety/correctness goes (See How (memory) safe is zig? for comparative details on its design philosophy) and posts like these suggest a worrying attitude toward Rust-level safety/correctness within the groups responsible for steering C++. On “Safe” C++ by Isabella “Izzy” Muerte Safe C++ proposal is not being continued by Simone Bellavia Why Safety Profiles Failed by Sean Baxter I’m having trouble remembering what I bookmarked it under so I can link it, but I’d also add the paper Stroustrup put out within the last few years which, to me at least, felt like a sign that the defensiveness various loud C++ developers feel toward the idea of Rust-like guarantees goes all the way to the top. (Which would be consistent with what On “Safe” C++ lays out.) I remember it being longer than A call to action: Think seriously about “safety”; then do something sensible about it .
ID: 277960
Author: Emma Smith
Created at: 2025-11-20 19:42
Number: 168
Clean content: Jelle Zijlstra: I like the idea of moving CPython towards Rust, but I feel the current proposal is so conservative that it doesn’t really get us there. You’re completely correct here, the pre-PEP does not get us to Rust being ubiquitous in CPython. I think we probably didn’t do a good enough job explaining why the approach is so conservative, and should explain more on a potential path to make Rust ubiquitous, so let me expand on that. I want to start by echoing @FFY00 Filipe Laíns: Personally, I thought of optionally introducing Rust more as a way to better understand how it would affect the community, and how well it would fit into the CPython codebase, and developers’ workflows. We intentionally want to keep the initial test as conservative as possible for a few reasons. Right now, the impact of introducing Rust at all is not fully known, so we want to make sure that it is both easy to back out of the change if it is untenable, and understand what workflows would break when Rust becomes required. One thing this thread has reinforced for me is that CPython is used all over the place, often in places we the core team are not aware of. The only way we can properly evaluate the potential impact of making Rust required is to start warning users we hope to do so and hear about places it would break, and what is needed to change to make Rust required. As for using Rust outside of extension modules, I think it could be used for experimental, opt-in interpreter features such as the JIT. I want to be cautious of this though because I don’t want the JIT to be in the state where it should become the default but making Rust required is a blocker to that. As everything else, it should be considered if migrating to Rust makes sense for the JIT. I’d also like to cite an article by Google researchers : There is a temptation, when introducing a new language, to pursue an aggressive timeline to justify the investment with short-term gains. Such an approach, fixated on overly ambitious goals, or rapid, sweeping change, invariably carries elevated risks of failure and can actively disincentivize future adoption by disrupting roadmaps and competing with other business objectives. A more powerful strategy, the one that proved so effective for Android, is to treat language adoption as a long-term investment in sustainable, compounding growth that supports other business objectives instead of competing with them. This approach patiently accepts initially lower absolute numbers to provide the necessary time for the new language to establish a foothold, build momentum, and achieve critical mass. In summary, for Android they found that moving to Rust is a long-term investment, that may not see immediate payoffs, but that moving to Rust is a long term success with significant payoffs. I realize this is a hard sell. But to me it makes a lot sense because there is a lot of learning and investigation to do related to integrating Rust into CPython. We need to spend the early period where Rust is allowed conservatively to build out the experience and support infrastructure for making Rust for CPython succeed. I could see a path where we start very conservatively with base64, then introduce a Rust version of a more central standard library module like json (as an optional replacement to the C version to start with), then make Rust required. But this is a guess at a plausible path forward, and the final path needs to be informed from experience. Jelle Zijlstra: in most cases, if we’d wanted a C accelerator, we’d have written one already. I would push back against this. One of the theses of this pre-PEP is that contributors are not inclined to write complex C code because it is difficult to do, thus projects like a C accelerator are not getting written. As an example, the performance of the json module has been significantly slower than other implementations for a long time. Yet a re-write in C would be daunting. I think Rust would excel in cases like this. Another example is actually the base64 module! `base64` module: Link against SIMD library for 10x performance. · Issue #124951 · python/cpython · GitHub We could use the Rust base64-simd crate for an easier, significant improvement to performance. Jelle Zijlstra: To get safety wins from using Rust, we have to stop using C. Not necessarily everywhere, definitely not everywhere immediately, but at least somewhere. Wholeheartedly agree with this, and that’s the goal with base64. We want to start somewhere , to better inform efforts elsewhere. Starting simply and minimally seems like the best path to allowing us to get an understanding without risk. Jelle Zijlstra: So for this proposal to be accepted, I feel there must be a clear path towards making it possible to replace existing C code with Rust, even if that means making Rust required. I think on the contrary we will see the greatest benefits for memory safety from making new code in Rust. A usenix paper found that the majority of vulnerabilities are in new code, as older code is battle-tested. So while I think we should enable replacing C code with Rust code where it makes sense, for example the json module, I think we will still see plenty of wins in new code too.
ID: 277965
Author: Jelle Zijlstra
Created at: 2025-11-20 20:04
Number: 170
Clean content: Emma Smith: I think on the contrary we will see the greatest benefits for memory safety from making new code in Rust. A usenix paper found that the majority of vulnerabilities are in new code, as older code is battle-tested. While most vulnerabilities may be in new code, I doubt they are in new modules . If we add a feature to (say) the JIT, or the JSON module, we have to write new C code.
ID: 277966
Author: Emma Smith
Created at: 2025-11-20 20:05
Number: 171
Clean content: Mark Shannon: What is the proposed API for rust? The section on implementation talks about using bindgen, but what is the underlying C API that you are binding? The limited API or the warts-and-all “unlimited” API? To interact with the interpreter today, we need to interface with C APIs. Currently the proof of concept binds to the unstable Python APIs as well as internal ones. We definitely want to build safe abstractions over the raw C APIs for common use cases, and that could perhaps use an API like handles. But it has to wrap the existing APIs like HPy does for CPython, so these necessarily need to be exposed to Rust. Mark Shannon: You mention PY_OBJECT_HEAD_INIT but that just couples rust code to the deep internals of the VM. To define a module, we need to have some way of defining a PyModuleDef, unless we want to introduce a new module initialization protocol (which is a large proposal in of itself). Therefore we need a pointer to a PyModuleDef, which needs it’s first member to be PyModuleDef_HEAD_INIT which internally expands to a structure with it’s first member being PyObject_HEAD_INIT. So some of this coupling is necessary as part of the module initialization protocol. Changing this protocol could be something we look into, but seems like it’s own rabbit hole 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.
ID: 277967
Author: Emma Smith
Created at: 2025-11-20 20:15
Number: 172
Clean content: Jelle Zijlstra: While most vulnerabilities may be in new code, I doubt they are in new modules . If we add a feature to (say) the JIT, or the JSON module, we have to write new C code. We absolutely need to write new C code for the JIT, the JSON module, or most other parts of CPython when making changes and adding features. However I think demanding immediate results across the code base from introducing Rust is infeasible. I’m curious as to your thoughts on the rest of my comment explaining why.
ID: 277968
Author: Jelle Zijlstra
Created at: 2025-11-20 20:18
Number: 173
Clean content: My thoughts are that a proposal that allows Rust only for optional extension modules is likely not useful enough to justify the cost of adding a new language. It can be a first step (in fact, it’s a very reasonable first step!), but that means there must be a plan to expand beyond it just being an optional part of building CPython. And that in turn means that we need to deal with the concerns that are being raised around bootstrapping and niche platforms.
ID: 277970
Author: Paul Moore
Created at: 2025-11-20 20:51
Number: 174
Clean content: Jelle Zijlstra: My thoughts are that a proposal that allows Rust only for optional extension modules is likely not useful enough to justify the cost of adding a new language. There’s been a number of comments about “optional extension modules” in this discussion so far. I want to make sure we’re 100% clear on what we mean by this, as I’m concerned we could end up measuring the wrong thing otherwise. As an end user, I have literally no interest in what language a stdlib module (or a core feature) is written in. It’s irrelevant to me. However, I have a strong interest in what is available in the stdlib and core. Optional modules are an awkward compromise here - can I use the module safely, or do I need to account for the possibility that it might not be available? This is exacerbated by the fact that the packaging ecosystem has no way to express a dependency on “Python >= 3.13, with the tkinter module available” (for example). If we introduce Rust by using it for stdlib modules, and as a result make them (and anything that depends on them!) optional, then we risk getting negative feedback which will look like it’s a downside of Rust, when it’s actually a downside of optional modules. I think the intention is not to do this, but rather to use Rust to create accelerators for existing pure-Python modules. But if that is the case, can we be clearer about this, so that people don’t get the wrong impression? Assuming we are talking about accelerators, I feel that @Jelle has a point. Using Rust to get a faster JSON module [1] will be a good way of finding out what’s involved in adding Rust to the core build process, but I don’t think it will provide much useful feedback on whether Rust provides sufficient benefit to be worth taking further. Which prompts the question - what would useful feedback look like? And how do we get it? I don’t think that’s been clearly established yet. I have to say that I don’t think anyone cares about a faster base64 module… ↩︎
ID: 277972
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.
ID: 277975
Author: Emma Smith
Created at: 2025-11-20 21:34
Number: 176
Clean content: Regarding optional extension modules, here’s a rough timeline I could see and why each step is chosen to be so. The goals of this stage are to get the initial build system changes set up, and start getting experience interfacing with the C code from Rust. Extension modules are a limited interface to the interpreter which minimizes the work to do for interoperability. Ideally we would also start warning users that we plan to eventually make Rust a hard requirement, and if this is a hardship for their environment, to please relate that to us. Only optional extension modules are allowed. Even more of a limitation, they should only be introduced where they would replace a C extension module (this could be things like base64 or json). The latter restriction exists to ensure we are not limiting access to new features to those who have Rust available. I picked the base64 module because it was simple but should exercise enough parts of the build system and C interop code, but we could just as well choose the json module. The goals of this stage are to make progress on improving portability and bootstrapping workflows based on feedback from stage 1. If we don’t gather feedback in stage 1 we could also start doing so here. More modules may be ported here to get even more experience with the C <—> Rust interfacing and overall developer experience. The goals of this stage are to ensure that we have resolved bootstrapping issues and warn of the impending requirement on Rust. Make Rust an opt-out feature of the interpreter. This is an even stronger warning of the up-coming requirement. At this point the vast majority of users should be able to build CPython with Rust enabled and bootstrapping issues should be resolved to greatest extent possible. I would say at this point new extension modules can be in Rust. The goal of this stage is to integrate Rust into core parts of CPython. Rust is required to build CPython. Rust can now be used across the CPython code base. This is one hypothetical scenario. We’re not going to propose this as the specification in the PEP. Jelle Zijlstra: My thoughts are that a proposal that allows Rust only for optional extension modules is likely not useful enough to justify the cost of adding a new language. It can be a first step (in fact, it’s a very reasonable first step!), but that means there must be a plan to expand beyond it just being an optional part of building CPython. There is simply too much to consider to resolve the bootstrapping and portability problems to have a concrete plan now . I think like PEP 703 did, we could leave an open question with some version of the above roadmap. But I don’t think we have enough information at the moment. The only way to tell what the impact of introducing Rust to CPython is to introduce Rust to CPython. In the above plan we start very conservatively to ensure we don’t break anyone’s workflows until we’re confident we can introduce Rust to core. I wouldn’t want to set hard timelines to any of this because we don’t know now when we should move to the next step in the process. So I think like free-threading, it would be best to start with step 1, then have a follow-up PEP when we are confident we have the information we need to move to the other steps.
ID: 277976
Author: James Webber
Created at: 2025-11-20 21:38
Number: 177
Clean content: 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. Surely this step was accomplished years ago, with the caveat that the Rust extensions aren’t usually “drop-in” replacements for an existing stdlib module, because that’s rarely what someone wanted to write. I don’t think anyone doubts that such a thing is possible, though? So what would be the next proposal after that?
ID: 277977
Author: Steve Dower
Created at: 2025-11-20 21:45
Number: 178
Clean content: James Webber: Surely this step was accomplished years ago Yeah, that’s my point. James Webber: So what would be the next proposal after that? Write one, prove it’s better, propose stdlib inclusion. It doesn’t even have to be a drop-in replacement, it can be a net-new module (but then the proposal needs to justify adding the module, which might make it too complicated). This is the standing process for adding something to the stdlib, and all that’s different is it’s the first proposal that would also bring in a new language. But then we are at least debating the merits in the context of something concrete, rather than something that feels very hypothetical.
ID: 277979
Author: James Webber
Created at: 2025-11-20 21:49
Number: 179
Clean content: I think that this is missing the point of this proposal, though. 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 [1] ”. that is, one that accelerates existing functionality ↩︎
ID: 277981
Author: James Webber
Created at: 2025-11-20 21:52
Number: 180
Clean content: That said–maybe it’s still too early for a PEP, and the real Proof-of-Concept is to set-up a full build? (edit: and the existing repo might be insufficient for that purpose if it doesn’t cover enough ground)
ID: 277982
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.
ID: 277984
Author: Steve Dower
Created at: 2025-11-20 21:55
Number: 182
Clean content: James Webber: The point is not “we really need a faster base64 , and specifically it should be written in Rust”. Sure, and the fact that we wouldn’t take this proposal seriously should also indicate that the lesser proposal of “we really need … Rust” isn’t going to be any more persuasive. On the other hand, “our drop-in replacement for json or re is 10x faster than the stdlib, can we merge it” is a far more interesting discussion to have. Emma Smith: Great! So then once we have a prototype of the abstraction your concerns will be assuaged? Probably not But my interest would be piqued by a production-ready replacement for an existing module, or a new module that we want in the stdlib anyway and the best way to get it is to bring in a Rust implementation.
ID: 277986
Author: Da Woods
Created at: 2025-11-20 22:05
Number: 183
Clean content: emmatyping: To define a module, we need to have some way of defining a PyModuleDef, unless we want to introduce a new module initialization protocol (which is a large proposal in of itself). Therefore we need a pointer to a PyModuleDef, which needs it’s first member to be PyModuleDef_HEAD_INIT which internally expands to a structure with it’s first member being PyObject_HEAD_INIT. So some of this coupling is necessary as part of the module initialization protocol. I think PEP 793 would disagree with this and probably be simpler from a Rust point of view because it doesn’t involve C macros (although that wasn’t the specific intent of it). (No comment on the larger context of the discussion…. just the specific paragraph)
ID: 277987
Author: Emma Smith
Created at: 2025-11-20 22:07
Number: 184
Clean content: Da Woods: I think PEP 793 would disagree with this and probably be simpler from a Rust point of view because it doesn’t involve C macros Fair point, and perhaps we should adopt PEP 793. I hadn’t realized the PEP was accepted, exciting!
ID: 277994
Author: Brénainn Woodsend
Created at: 2025-11-20 22:44
Number: 185
Clean content: Slightly tangential but I find optional stdlib components to be a menace and would really like their proliferation to be minimised. For pre-built Python installations like those on python.org or python-build-standalone , there’s nothing optional about them – someone will need them therefore they must be included therefore everyone gets them whether they’re needed or not. For those installing from source, it’s a footgun with remediation steps so platform specific that they can rarely even be written down in any detail. For those building Python for other people, it’s both. For distro-provided Python, it’s a surprise extra system dependency that rarely follows any predictable pattern and doesn’t correlate to anything in a lockfile. I’ve spent way more time debugging tkinter installations than even monster PyPI packages like Qt.
ID: 277998
Author: Emma Smith
Created at: 2025-11-20 22:55
Number: 186
Clean content: Brénainn Woodsend: Slightly tangential but I find optional stdlib components to be a menace and would really like their proliferation to be minimised. I have heard from a number of people a similar sentiment. I think therefore it’d be best if a new Rust module was a replacement for an existing C module that could act as a fallback, rather than an entirely new module with no fallback.
ID: 277999
Author: Brénainn Woodsend
Created at: 2025-11-20 23:01
Number: 187
Clean content: In that case, perhaps Python’s build system would have to be pushy and fail without rust by default unless some --use-legacy-c-{module}-implementation flag is given? Otherwise, I suspect that many of the people downstream we want feedback from aren’t going to notice it.
ID: 278001
Author: Neil Schemenauer
Created at: 2025-11-20 23:37
Number: 188
Clean content: I feel the current proposal is so conservative that it doesn’t really get us there. I think that’s okay.  This is going to be a many-year, perhaps on the order of decades, project.  The first step is to add Rust as an optional feature of the CPython build.  That will allow us to solve some tricky problems about how we can make Rust and C co-exist.  And, we can find out how many platforms are going to be affected by this (e.g. they can’t get the optional features to build) and fix that for as many platforms as we can. This initial step doesn’t necessarily help with code safety, API cleanliness, or performance aspects.  I’m sure others will disagree but, to me, the benefits that Rust can bring on those is clearly demonstrated in other projects.  We don’t need to prove those specifically for CPython. Edit: maybe it’s useful to enumerate what I think are the clear benefits that Rust could bring.  I’m not a Rust programmer so knowledgeable people will need to correct me if I’m wrong (as I’m sure they will gleefully do). array bounds checking: in the year 2025, it’s crazy we are using a programming language that doesn’t do this.  Yes, there can be extra overhead.  No, you are not smart enough to get it correct. use-after-free and other memory lifetime bugs.  Rust’s borrow checker avoids most of these at compile time. integer overflow: Rust doesn’t prevent it but at least it defines what happens.  Undefined behavior is bad. scope based cleanup: I’ve heard that the C language standard might eventually be getting something like __attribute__((cleanup(...))) .  It’s probably going to be decades before CPython could actually rely on C compilers supporting that.  This pattern comes up so often and it’s painful we don’t have a built-in language feature that supports it. There are other benefits and conveniences but these are the big ones, IMHO.
ID: 278011
Author: Jeong, YunWon
Created at: 2025-11-21 01:50
Number: 189
Clean content: nas: array bounds checking: in the year 2025, it’s crazy we are using a programming language that doesn’t do this. Yes, there can be extra overhead. No, you are not smart enough to get it correct. use-after-free and other memory lifetime bugs. Rust’s borrow checker avoids most of these at compile time. integer overflow: Rust doesn’t prevent it but at least it defines what happens. Undefined behavior is bad. scope based cleanup: I’ve heard that the C language standard might eventually be getting something like __attribute__((cleanup(...))) . It’s probably going to be decades before CPython could actually rely on C compilers supporting that. This pattern comes up so often and it’s painful we don’t have a built-in language feature that supports it. Adding more details about the points. array bounds checking is on by default, but when the overhead matters, explicitly skipping check is possible for each element access.. integer overflow panics on debug build. it has both checked operation and wrapping operation. checked operation is default on debug build. wrapping operation is default on release build. Of course each operation can be explicitly marked as checked if it is useful for runtime. Otherwise explicitly marking as wrapping is also useful when it is intended.
ID: 278013
Author: H. Vetinari
Created at: 2025-11-21 03:25
Number: 190
Clean content: Neil Schemenauer: I’ve heard that the C language standard might eventually be getting something like __attribute__((cleanup(...))) . It’s probably going to be decades before CPython could actually rely on C compilers supporting that. This is the defer proposal, which currently exists as a TS (like a branch of the C standard). Here’s an overview of the thing (and the procedural reasons for the TS) in blog post format. Clang has a mostly ready PR for this [1] . The GCC patch set is at v5 AFAICT. Long story short, this should be available in compilers relatively soon [2] and may make it into C2y if people like the feature and let people on the committee know. However you’re likely right about the timelines. Anything before 2040 for broad availability (i.e. defer as part of the standard, not a TS, and implemented across all major compilers present on LTS distros) would be wildly optimistic IMO [3] . Who knows how the world (and CPython) looks like by then… check out the number of reactions as a barometer for people’s interest in this ↩︎ MSVC’s C standard conformance has been horrible since C99; you’d be better off using clang-cl on windows than wait for MSVC on anything. They still haven’t gotten C99 or C11 finished, and ~zero for C23. ↩︎ On the other hand, if people were willing to replace MSVC with clang-cl and rely on -fdefer-ts , you could probably do it in 5 years, assuming the benefits are so substantial that this would be worth it. ↩︎
ID: 278044
Author: Antoine Pitrou
Created at: 2025-11-21 11:59
Number: 191
Clean content: Emma Smith: PyO3 already has 8 years of experience for us to steal re-use refining their APIs. You probably meant “borrow”.
ID: 278071
Author: Antoine Pitrou
Created at: 2025-11-21 19:51
Number: 192
Clean content: Ok, here’s a potential exercise if the optional module story isn’t appealing. The memoryview object is written in C and the performance of memoryview.index is currently horrid due to being written in a very naive way . Accelerating it in C involves generic programming in a language that doesn’t provide any decent metaprogramming. But if an alternate implementation of memoryview was written in Rust, then perhaps those accelerations would be much easier to implement (of course, you also need to develop some basic infrastructure for that: for example, a facility to dispatch to different generic specializations depending on the memoryview format ). So we could have an optional implementation of memoryview in Rust, and fallback on the C one on Rust-less platforms.
ID: 278155
Author: Emma Smith
Created at: 2025-11-22 18:11
Number: 193
Clean content: Thank you for bringing this up! I think memoryview could be a very appealing option for demonstrating Rust. Rust’s generics could make index a lot easier to implement as you say. I also think it has made me reconsider where to draw the line of where it is okay to re-write things in Rust. I want to start this by re-iterating that we do not want to go and just re-implement everything and anything in Rust to start with. At least until we have a lot more experience with Rust in CPython, and given contributors time to learn and try working with Rust, we should select up to a few experimental changes to make, and review our experiences after making those changes. Areas re-written in Rust should have a justification for doing so, like memoryview. We should also consider if the most active contributors to that portion of the codebase are comfortable with Rust being introduced. That being said I think we could expand where Rust could be implemented to include built-in objects, or really any part of the interpreter, if we also keep a C fallback of the implementation. For memoryview, we could keep the current implementation as a compile-time fallback and introduce a Rust version that takes advantage of it’s meta-programming (if needed) and generics. This may mean we’d need to maintain two versions of certain parts of the interpreter for a little while, but I think getting more experience across the code base would be worth the extra effort. The maintenance effort of keeping two implementations should be considered  as part of evaluating where to introduce Rust. With C compile-time fallbacks, there should be no cause for concern on portability or bootstrapping. This seems like a nice compromise between the very limited “Rust only in extension modules” and “Rust can go anywhere and we need to figure out bootstrapping”. Obviously the trade-off is maintenance burden, but I think if we’re smart about what parts we implement in Rust, we can minimize the effort. Curious what others think!
