Build1 publisher3 min readPublished
CPython's Rust plan gives packagers two optional releases before the toolchain can become required
Rust for CPython's team proposes shipping optional Rust in Python 3.16 in October 2027 and requiring a Rust toolchain no earlier than Python 3.18 in 2029. Distributors are asked to try the optional build first and report platform breakage in time for fixes around Python 3.17.
The Engineer · Build desk
What happened
- The team behind the proposal is about 60 developers in a Discord channel, including a few Python core developers and a delegation from the Rust project.
- Core developers Kirill Podoprigora and Emma Smith lead the team and wrote the PEP draft, and David Hewitt presented the plan at the 2026 Language Summit as its ambassador.
- The team picked zlib as the first module to get a Rust implementation because it wanted a "significant improvement" from a "small scope".
- Hewitt said Rust's platform support had "widened since last year" and was becoming "less and less of a concern".
- The team says Rust will not make ported code bug-free and proposes property-based testing and fuzzing during porting.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- decision Distributors building 3.16 choose whether to add a Rust toolchain to their build environments. Declining costs nothing in that release, but only builds that opt in feed the platform fixes planned for 3.17.
- constraint A supported platform without a working Rust toolchain has two optional releases to surface the gap, because once Rust is required it cannot build CPython at all.
- constraint CPython's own Rust API stays private until the release that makes Rust required, October 2029 at the earliest, so Rust extension authors have PyO3 and Maturin and no official CPython Rust API until then.
For anyone who builds Python, the first Rust would be opt-in. The Rust code in 3.16 would be completely optional, with the existing C code kept as a fallback [13]. A build host without a Rust compiler still gets the C zlib module [13]. I think that is the right design for a first release. Distributors can test the Rust path on their own hardware while the release still ships working C code [9][13].
The proposed sequence, as the summit writeup lays it out:
1. Summer 2026: build system, CI and a Rust API proof of concept [15]. 2. Late 2026: a PEP defining the success criteria [15]. 3. Python 3.16, October 2027: an optional Rust backend for zlib and a private Rust API [16]. 4. Python 3.17, October 2028: platform issues resolved, and Rust in io, json, xml, memoryview and the parser [17]. 5. October 2029 or later: the Rust build becomes required and a public Rust API is published [18].
Counted in releases, distributors get two with Rust optional, 3.16 and 3.17, before 3.18, the earliest version that could require it [1]. The writeup puts that requirement at least three years away [14]. The loop for platform bugs is shorter. It runs about a year, from 3.16 builds to the planned fixes around 3.17 [2]. Most of the Rust testing for CPython's 20 officially supported architectures and platforms, across Tiers 1, 2 and 3, would have to happen inside that year [7][9].
The writeup opens on the line "No one said 'don't do this' last year" [21]. Absence of objection is a lower bar than acceptance, and the PEP is still a draft [1]. David Hewitt brought proposed timelines, phases and success criteria to the summit [3]. The writeup does not list the criteria, and the PEP meant to define them is due in late 2026 [15].
The case for Rust starts from crash reports. Issues labeled "type-crash" have been rising steadily [4]. "We've been making some big technical bets," Hewitt said, pointing to the new parser, the JIT and free-threading [5]. He cited Android, where the experience since adopting Rust has been "fewer revisions for patches of the same size" [6]. That result comes from someone else's codebase and review process. For it to carry over, CPython's new crashes would need to come mostly from the bug classes Rust mitigates, and the ported code would need to sit where those crashes happen [12]. The first port is zlib [16]. The parser is in the 3.17 group [17].
The other constraint is who can review the code. Rust knowledge is "not universal amongst core developers," according to the writeup, and the plan answers by "targeting small portions" of CPython [10]. "1 million lines of C code can't be ported all at once," Hewitt said [11].
What to watch
- The Rust for CPython PEP due in late 2026, and whether its success criteria say what the zlib backend must show before Rust spreads to io, json, xml, memoryview and the parser.
- The Summer 2026 build system and CI work, and what it adds to CPython's build requirements on each supported platform.
- Platform reports from distributors trying the optional 3.16 build, especially on Tier 2 and Tier 3 platforms, before the fixes planned around 3.17 in October 2028.