CPython Targets Python 3.16 for First Rust Code as Project Clears Build System Hurdle and Plots PEP Timeline
The Rust for CPython project has achieved cross-platform builds in CI and shifted its target from Python 3.15 to 3.16, setting a July deadline to submit a formal Python Enhancement Proposal that would make Rust a build-time dependency of the reference interpreter.
Overview
The effort to introduce Rust into CPython, Python’s reference interpreter, has reached its first concrete engineering milestone. The Rust for CPython project announced in an April 2026 progress update that its fork of CPython now builds successfully with Rust across all tested platforms in continuous integration, clearing a prerequisite that had blocked forward progress for months.
The project has also revised its timeline, shifting its target from Python 3.15 to Python 3.16 as the first release to include Rust code. The change gives the team until Python 3.16’s beta 1 deadline in May 2027 to design an internal Rust API, implement a reference extension module, and navigate a formal Python Enhancement Proposal through community review.
What We Know
Core developers Emma Smith and Kirill Podoprigora launched the Rust for CPython initiative in late 2025, opening a pre-PEP discussion on the Python community forum. The proposal argues that CPython’s substantial C codebase suffers from memory and thread unsafety that leads to crashes and potentially exploitable security bugs — problems that Rust’s compile-time guarantees are designed to prevent.
The April update outlines a month-by-month roadmap through the summer. In April, the team plans to finalize the design of an internal Rust API and select a single extension module as the initial implementation target. May will bring a sprint at PyCon US 2026 in Pittsburgh, where Smith is scheduled to present the project on May 16. The formal PEP drafting process is expected to begin in June, with a completed draft submitted for discussion in July.
The internal Rust API is a critical design decision. It will define how Rust code interacts with CPython internals, but the project has stated that this API will remain private until a separate, future PEP stabilizes and publicizes it. This approach mirrors how CPython has historically introduced internal C APIs before exposing them to third-party extension authors.
Guido van Rossum, Python’s creator, has endorsed the effort, calling it “a great development” in the pre-PEP discussion thread. Nathan Goldbaum, maintainer of the PyO3 Rust-Python binding library, noted that official Rust bindings within CPython would reduce the maintenance burden that PyO3 currently bears when supporting new Python versions.
The Rollout Plan
The phased approach described in the pre-PEP discussion spans three Python release cycles. In Python 3.15, expected in October 2026, the configure script would warn if Rust is not available, but all Rust usage would remain strictly optional. In Python 3.16, the configure script would fail without Rust unless users explicitly pass a --with-rust=no flag. By Python 3.17, projected for 2028, Rust could become a hard build-time requirement.
However, Smith and Podoprigora scaled back the later phases after community pushback. Requiring Rust at build time by 2028 has been indefinitely postponed, and the project currently limits Rust to optional extension modules for the foreseeable future.
The initial scope calls for reimplementing a single performance-critical standard library module in Rust, such as base64. This strategy is deliberately conservative: rather than touching CPython’s core interpreter loop or garbage collector, the team aims to demonstrate that Rust can coexist with C in the build system and produce measurable benefits in a contained area.
Platform Concerns
CPython officially supports 20 platforms, and The Register reported that 11 of them are classified as Tier 3 in Rust’s own support matrix — the lowest level, meaning they may lack a working standard library or compiler. Platforms without any Rust support include RISC OS, HP PA-RISC, Mac OS X on PowerPC, and CentOS Linux 6.
Michal Gorny, a Gentoo developer, raised concerns during the pre-PEP discussion that Rust’s limited support for niche architectures would burden Linux distributions that maintain packages for minority platforms. Steve Dower argued that optional modules should live in separate repositories rather than adding mixed-language complexity to CPython’s core codebase.
The proposal also introduces a circular dependency challenge: building Rust requires Python, while building Python would eventually require Rust. This bootstrap problem does not exist today and would need to be resolved before Rust becomes a hard requirement.
What We Don’t Know
The project has not disclosed which extension module it will target first for the Rust implementation. The choice matters because it will set expectations for the performance improvements and safety guarantees that Rust can deliver in practice compared to the existing C code.
It also remains unclear how the Python Steering Council will weigh the competing concerns when the PEP arrives for a formal vote. The pre-PEP discussion surfaced significant opposition alongside support, and the council has historically moved cautiously on changes that affect CPython’s build dependencies.
Whether the timeline will hold is another open question. The project has already slipped once, from Python 3.15 to 3.16, and the PEP review process can extend for months if contentious issues arise.
Analysis
The Rust for CPython effort follows a pattern now visible across several major open-source projects. The Linux kernel formally ended its Rust experiment in Linux 7.0, making the language a permanent part of kernel development. Chromium and Android have both expanded their Rust footprints over the past two years. If CPython follows suit, Rust will have established itself as the default choice for hardening C-heavy infrastructure projects against memory safety vulnerabilities.
The conservative scope — one optional module, an internal API, a multi-year ramp — reflects lessons learned from those earlier adoptions. The Linux kernel’s Rust integration took three years of experimental status before gaining full acceptance, and the CPython team appears to be following a similarly gradual path.
For the broader Python ecosystem, the most immediate practical effect may be indirect. If CPython ships with official Rust bindings, it could lower the barrier for the growing number of Python libraries that already use Rust internally through tools like PyO3 and maturin. The long-term question is whether Rust will remain confined to performance-sensitive modules or eventually reshape how CPython itself is built and maintained.