Why bring Rust into CPython?
At the Python Language Summit 2026, David Hewitt outlined a concrete roadmap for using Rust inside the CPython core. The main motivation: tackle the growing number of type-crash issues and improve safety as CPython adds complex features like the new parser, the JIT, and free-threading.
David spoke as an ambassador for the Rust for CPython team, led by core developers Kirill Podoprigora and Emma Smith (authors of the Rust-for-CPython PEP draft). Around 60 developers are involved via Discord, including several Python core devs and a delegation from the Rust project, many with prior experience integrating Rust into Android and the Linux kernel.
Rust and Python already coexist in the ecosystem through PyO3 and Maturin. The new proposal is to move that collaboration into CPython itself, not just third-party packages.
Roadmap: starting with zlib
The plan is intentionally incremental:
- Summer 2026 – build system & CI support, Rust API proof-of-concept
- Late 2026 – PEP defining success criteria
- Python 3.16 (Oct 2027) – optional Rust backend for
zlib, with the existing C code kept as a fallback - Python 3.17 (Oct 2028) – fix platform issues, use Rust in more places (
io,json,xml,memoryview, parser internals) - Some 3.18+ release (Oct 2029+) – Rust build becomes required, and a public Rust API ships
The first target, zlib, was chosen for a small but high-impact change:
- zlib compression is heavily used by Python packaging;
- if accepted, almost every
pip installin Python 3.16 could speed up; - it exercises using an external Cargo crate (
zlib-rs, used by Firefox,uv, and Cargo, and often faster than zlib/zlib-ng), forcing the team to design the Rust-dependency story early.
Rust API design and success criteria
David showed a sketch of a Rust API using a #[pyfunction] attribute, Python<'_> context, smart pointers like Py<...>, and idiomatic Result-based error handling. In the example decompress function, a buffer is allocated and automatically dropped on scope exit instead of being manually freed as in C.
The team is clear that Rust is not a magic bullet: while it removes whole classes of memory-safety bugs, logic errors remain. They plan to lean on property-based testing, fuzzing, and conservative engineering practices during the port.
Proposed success criteria include:
- A majority of active core developers are open to using the Rust API;
- No meaningful slowdown in CPython performance benchmarks;
- All tiered platforms supported by CPython can also be built with Rust, and distributors report that enabling Rust is manageable.
There was also discussion about not over-optimizing for C-API familiarity ("don’t make compromises for the dinosaurs"), the fact that this is not a rewrite (projects like RustPython already exist), and the long-term risk of pulling in too many Cargo dependencies.
In practice, CPython is expected to remain a dual-language project for a long time. But if the roadmap succeeds, Rust could eventually become a required part of building CPython, backed by a stable public Rust API.
Source: Python Insider
