Rust for CPython Progress Update April 2026

Core Development
1

To head off unfocused discussion, I ask that folks refrain from making this thread a discussion about whether or not Rust should be introduced into CPython. There will be a PEP thread for that later this year!

We (the Rust for CPython community) wanted to provide an update on where the project is and our current plans from now to a Python Enhancement Proposal (PEP) for introducing Rust into CPython.

Recent work

Since the pre-PEP thread, we’ve been working on making the reference implementation build system more robust across the platforms CPython supports. We’re now successfully building CPython with Rust in our fork’s CI on all tested platforms.

We’ve also had a number of productive discussions with the Rust team, who have been incredibly generous to meet with us to discuss the needs of the CPython project and how best to address issues we face with integrating Rust with CPython. I’m incredibly grateful to everyone who has joined those meetings.

We’ve also had some discussions about the design of a Rust API for CPython. You can see issues tagged api-design which cover the critical components of the API design. We’d love to get more input on designing the Rust API, so please see below about contributing if you are interested in working with us on the Rust API. As a reminder, this API will remain internal until a later PEP stabilizes it and makes it public.

Roadmap to a PEP

Since the pre-PEP, we’ve decided that we will be targeting Python 3.16 rather than 3.15 as the first Python version to include Rust code. This gives us a year to make the reference implementation the best it can be and plenty of time for discussion of the PEP.

The below timeline is subject to change, but covers a rough plan of what and when we hope to accomplish things:

  • March
    • Done! Finish the build system work, ensuring platforms tested in CPython CI are green
  • April
    • Start planning the internal Rust API design
    • Select a single extension module to have a Rust implementation in 3.16
  • May
    • Finalize a plan for the internal Rust API design
    • Start implementing the internal Rust API
    • Sprint at PyConUS on the internal Rust API and the extension module
  • June
    • Start writing the PEP
  • July
    • Finalize the PEP draft
    • Submit the PEP and begin discussion

We recognize introducing Rust is a significant change, and expect the PEP discussion to be lengthy, so we want to make sure there is ample time to discuss it prior to 3.16 beta 1 in May 2027.

Contributing

Interested in contributing to the Rust for CPython project? Please join our Discord! We have meetings every Monday at 12:00PM PDT to discuss the project. We’d love to have more folks join those meetings and work with us on Rust for CPython!

49 Likes
2

Was wondering about the current status here, but couldn’t find much on discourse; for the benefit of other people that might be interested: there’s been a very recent blog post from the language summit. For now, 3.16 is still the goal.

4 Likes
3

Ty for the link.

The Rust for CPython team has selected the zlib module as the first module to be given an optional Rust implementation because they “wanted to achieve a significant improvement” with a “small scope”.

The result will be surely impressive, but I’m very curious about a Rust implementation, or a partial rewrite of critical parts, of marshal. I suppose this will be not only an example of how Rust can speedup Python, but also how it can make it safer.

The problem is that I suppose marshal has not a “small scope” :slight_smile:

2 Likes
4

Of course!

We’ve been working on the API design for the past few months. There’s currently an open PR with the draft if anyone would like to look it over: Add initial draft of Rust API design document by emmatyping · Pull Request #45 · Rust-for-CPython/cpython · GitHub, though I will note it is both dense and lengthy!

I am hoping to get consensus on that design or something similar to it by early November, so that we can build out the API and zlib implementation and start working on the PEP. If all goes to plan, we can get the PEP submitted in December/early January and have a number of months to discuss the change prior to the beta cutoff.

I think this definitely could be investigated for 3.17 if the PEP is approved. One advantage of zlib is that the actual C API surface used is relatively small, so we can start with a smaller Rust API. marshal would require supporting a lot more of the C API I expect.

5 Likes