Rust for CPython: Language Summit 2026 Proposal Sets Timelines and Success Criteria

At the Python Language Summit 2026, David Hewitt presented the Rust for CPython project's phased plan: timelines and success criteria. First discussed at PyCon US 2025, the project is led by core developers Kirill Podoprigora and Emma Smith.

The team counts around 60 developers in a Discord channel, including Python core developers and a delegation from the Rust project. Many have experience integrating Rust into Android and the Linux kernel.

Why Rust?

Hewitt pointed to a steady rise in issues labeled "type-crash": 82 in 2021, 222 in 2025, with 2026 projected at around 353. New "big technical bets" such as the parser, the JIT and free-threading may be contributing, and Rust could help.

First target: the zlib module

The first module lined up for an optional Rust implementation is zlib, using zlib-rs, which is used by Firefox, uv and Cargo and is faster than zlib. Because zlib compression is widely used by Python packaging, almost every pip install in Python 3.16 would get faster.

The Rust API proof-of-concept is due in summer 2026, with a PEP defining success criteria in late 2026. Python 3.16 (October 2027) would ship the Rust version of zlib and a private Rust API; Python 3.17 (2028) would bring Rust to more modules, including io, json, xml, memoryview and the parser. Rust would become required no earlier than Python 3.18 (2029).

Concerns and debate

Hewitt acknowledged adoption is a social challenge as much as a technical one: Rust knowledge is not universal among core developers, so the plan covers small portions of CPython, since "1 million lines of C code can't be ported all at once." Platform support, once the biggest worry, has widened.

Larry Hastings asked why the project wasn't a rewrite; Hewitt noted that RustPython already exists. He said "CPython should not be written in Rust for the sake of Rust" and that CPython will stay a dual-language project for a long time. Pablo Galindo Salgado called pulling dependencies from Cargo a potential "showstopper"; Hewitt answered that external dependencies would be kept to a minimum and that building CPython would not require Cargo.

Success criteria

For previous big changes such as the JIT and free-threading, success criteria were defined in advance, so Hewitt argued similar tests are needed: a majority of core developers open to using the Rust API ("open", not "familiar"), no meaningful benchmark slowdown, and support for all tiered platforms.