Is CPython Moving to Rust? What the Proposal Says
Python’s core team is proposing optional Rust code in CPython 3.16, starting with zlib. What’s proposed, what isn’t decided, and what it means for you
Python’s core developers are weighing a plan to let CPython use Rust, starting with one optional module in Python 3.16. Nothing has been accepted yet, and a full Rust requirement is at least three years away. If you write pure Python, none of it changes your code. It does explain some of why Python tooling keeps turning up written in Rust, and it could make pip install faster.
Status as of 5 October 2026: this is a proposal. A “Pre-PEP” was opened for discussion in November 2025, and at the time of writing no PEP number has been assigned. Details below come from the Python Software Foundation’s Language Summit 2026 write-up and the Pre-PEP thread, and could change.
What’s actually proposed
The Rust for CPython project is led by core developers Emma Smith and Kirill Podoprigora, who are writing the PEP draft. David Hewitt acted as the team’s ambassador at the 2026 Language Summit, and the wider team is around 60 developers, including a few Python core developers and a delegation from the Rust project. The proposed phases:
| When | What |
|---|---|
| Summer 2026 | Build system, CI, and a proof-of-concept Rust API |
| Late 2026 | A PEP defining the success criteria for Rust in CPython |
| Python 3.16 (October 2027) | An optional Rust backend for the zlib module and a private Rust API. The C code stays as a fallback |
| Python 3.17 (October 2028) | Platform issues resolved, with Rust spreading to more areas (io, json, xml, memoryview, the parser) |
| 3.18 or later (2029+) | Earliest point Rust could become required to build CPython, alongside a public Rust API |
Why Rust, according to the team
The stated case is about reliability. The number of GitHub issues labelled “type-crash” has been rising steadily, and the presenter suggested CPython’s big technical bets, the new parser, the JIT, and free-threading, may be one reason. Rust, they argue, could reduce that class of bug. They point to Android’s experience, where Rust has meant fewer revisions for patches of the same size.
The team was careful not to oversell it. Using Rust doesn’t make code free of bugs or security issues, and correctness problems can still happen, so the plan includes property-based testing and fuzzing during any port. Rust is also already common in the Python ecosystem through PyO3 and Maturin, and the Pre-PEP cites the 2025 Language Summit for the claim that 25-33% of third-party extension modules use Rust, especially new ones.
Why zlib goes first
The team chose zlib because it is a small module where Rust could still make a visible difference. The proposed implementation uses zlib-rs, which the team describes as heavily tested and used by Firefox, uv, and Cargo, and faster than zlib and zlib-ng on many platforms. Because it depends on an external Cargo package, it also forces the build process for Rust dependencies to be designed and exercised early. The pitch is that nearly every pip install on Python 3.16 would speed up, since zlib compression is widely used by Python packaging. That’s the team’s claim and conditional on the proposal being accepted.
What it means for you
- Writing pure Python: nothing changes.
- Installing packages: possibly faster
pip installfrom 3.16 if the proposal goes ahead. - Writing extension modules: a public Rust API is on the roadmap, but for much later. The sources I read don’t say what happens to the C API, so check the PEP when it appears.
- Building CPython or packaging it for a distro: Rust would be optional in 3.16, and the team asks distributors to try it and report platform problems in time to fix them for 3.17. Rust would eventually become a build requirement. The team says building CPython wouldn’t require Cargo, because the Rust sources would be vendored outside the main tree.
- Contributing to CPython: Rust knowledge isn’t universal among core developers, which is why the plan targets small, self-contained modules rather than a wholesale port.
The objections
The Language Summit discussion shows the project is far from settled.
- “Why not a rewrite or a fork?” Larry Hastings asked why the team didn’t prove it as a fork, and said he wasn’t keen to learn Rust to work on CPython. The answer was that a separate Rust implementation, RustPython, already exists but isn’t as fast as CPython, and that CPython “should not be written in Rust for the sake of Rust,” in David Hewitt’s words. He also said it would be disingenuous to claim Rust would stay optional forever.
- Dependencies. Pablo Galindo Salgado warned that pulling dependencies from Cargo would be a huge problem and a potential showstopper, because CPython vendors a small, selective set of dependencies and release managers must cut new releases whenever one of them has a vulnerability. The response was to keep external dependencies to a minimum (
zlib-rswould be the only one) and vendor them. - API design. Thomas Wouters argued against making compromises for people used to the C API, suggesting the Rust API be designed from first principles. The team’s view is that there are places to lean into Rust, such as dropping resources when they go out of scope, but that core developers will often be looking at both APIs at once.
- Platforms. CPython officially supports 20 architectures and platforms across its tiers. The team says Rust’s platform support has widened since last year and is a smaller worry than it was.
How it would be judged
For the earlier big changes, the JIT and free-threading, the project set explicit success criteria first, and the team expects to do the same here. The suggested criteria are that a majority of active core developers are open to using the Rust API, that there is no meaningful slowdown on CPython’s benchmarks, and that Rust supports every tiered platform without making life hard for distributors. The team also plans to survey core developers on their Rust experience before moving beyond the experimental stage.
Why it fits a wider trend
You may have noticed how much Python tooling is already built on Rust. Ruff and uv are Rust tools, Polars is a Rust-based DataFrame library, Robyn puts a Rust engine under a Python web framework, and Pydantic v2 moved its validation core to Rust (see what Pydantic is). This proposal is about bringing the same language into the interpreter’s own codebase, rather than only around it. For the other large changes underway in CPython, see the guides on free-threading and the 3.15 JIT compiler.
What to watch
The PEP that defines the success criteria, expected in late 2026, is the next real milestone. After that, whether the optional zlib backend appears in the run-up to 3.16 in 2027 will show how seriously the core team is taking it. Until the PEP is accepted, treat every date above as a proposal.
Frequently Asked Questions
Is Python being rewritten in Rust?
No. The proposal is to let CPython use Rust for some optional modules, starting with zlib, while the existing C code stays as a fallback. The project’s own presenter said CPython should not be written in Rust for the sake of Rust, and that it would be a dual-language project for a meaningful amount of time.
When would Rust be required to build CPython?
Under the proposed roadmap, no earlier than Python 3.18 in 2029. Python 3.16 (October 2027) would only add optional Rust code. None of this has been accepted yet: a PEP defining the success criteria is expected in late 2026.
Will this make Python faster?
The only concrete claim so far is that a Rust zlib module would speed up pip installs, because zlib compression is widely used by Python packaging. One of the proposed success criteria is that Rust must cause no meaningful slowdown on CPython’s benchmarks, so a general speedup isn’t being promised.
Do I need to learn Rust to use Python?
No. If you write pure Python, nothing changes. Rust only matters if you contribute to CPython itself, build it from source, or write extension modules that would eventually use a public Rust API, which is on the roadmap for much later.