CPython Rust Proposal: Memory Safety vs Bootstrap Hell

Two CPython core developers want to rewrite Python’s core in Rust. There’s one problem: building Rust requires Python, and under this proposal, building Python would require Rust. The circular dependency creates a chicken-and-egg problem that could lock legacy platforms out of modern Python and force every developer to navigate bootstrap hell. On November 18, 2025, Emma Smith and Kirill Podoprigora published a pre-PEP proposal that has the Python community split between memory safety gains and infrastructure nightmares.

The Proposal: Rust Mandatory by 2028

The plan is phased but aggressive. Python 3.15 (2026) warns if Rust is unavailable. Python 3.16 (2027) fails to build without --with-rust=no. Python 3.17 (2028) makes Rust mandatory throughout CPython’s codebase. They’ve rewritten the _base64 module as proof of concept, using bindgen to generate C API bindings. This isn’t speculation—it’s working code from core developers.

The Bootstrap Paradox: You Need Python to Build Rust

Here’s where it breaks. Rust’s compiler bootstrap requires Python. If CPython requires Rust to build, you face a circular dependency: you need Python to get Rust, but you need Rust to get Python. The proposed workaround is to build an older Python first, use that to build Rust, then use Rust to build the newer CPython. On a fresh system without either language installed, developers hit a three-stage bootstrap process instead of a single build.

This mirrors the Debian APT situation. Debian’s package manager recently added a Rust dependency, immediately stranding platforms like HP PA-RISC that lack robust Rust support. The CPython proposal follows the same path: solve one problem (memory safety) by creating another (bootstrap complexity and platform abandonment).

11 of 20 Platforms Are Tier 3 for Rust

CPython officially supports 20 platforms under PEP 11. Of those, 11 are Tier 3 for Rust—the lowest support tier, meaning “best effort, may or may not work.” Four platforms have zero Rust support: RISC OS, HP PA-RISC, Mac OS X PowerPC, and CentOS Linux 6. By Python 3.17 in 2028, organizations running these systems would be locked out of modern Python entirely.

One community member put it bluntly: this proposal “would effectively eliminate modern Python on several platforms.” That’s not hypothetical. When a language runtime adds a hard dependency on a toolchain with spotty platform support, legacy infrastructure users face a binary choice: abandon the platform or stay on unsupported Python versions indefinitely.

The timeline gives about three years of runway—Python 3.15 in 2026, mandatory by 3.17 in 2028—but for enterprises on older systems, three years isn’t long to migrate critical infrastructure.

Why They Want This: Memory Safety Gains Are Real

CPython’s C codebase has invalid memory accesses. Rust provides compile-time memory safety guarantees that eliminate entire bug classes: no use-after-free, no double-free, no buffer overflows, no data races. The Linux kernel adopted Rust in October 2022 for this reason—memory safety bugs account for two-thirds of kernel CVEs. Rust eliminates 66% of vulnerabilities by design.

The Python ecosystem is already moving this direction. At the 2025 Python Language Summit, core developers reported 25-33% of new PyPI extension modules use Rust instead of C. For new projects, one in three developers choose Rust. This isn’t fringe—it’s an ecosystem trend backed by adoption data.

Community Divided: Guido Supports It, Core Devs Push Back

Guido van Rossum, Python’s creator, called the proposal “a great development,” though he acknowledged “a full rewrite in Rust won’t work.” His endorsement carries weight, but core developers aren’t unanimous.

Paul Ganssle raised build time concerns. Rust compilation is slow. If CPython builds take twice as long, fast iteration cycles—one of CPython development’s strengths—suffer. MegaIng pointed to Linux kernel tensions between C and Rust maintainers, warning that CPython could see similar maintainer attrition as “different types of programmers” clash over tooling and style.

Antoine Pitrou emphasized that Rust alone isn’t enough. Without safe abstractions around the FFI layer, developers still face “tedious, unsafe, error-prone low-level pointer juggling” just like C. The proposal needs better answers on abstraction design before core components get rewritten.

Some community members framed this as “Rust activism”—Rust evangelists pushing their preferred language regardless of practical costs. Techrights published an article titled “Python Risk From Rust Activists,” reflecting a sentiment that this proposal prioritizes language ideology over Python’s accessibility and platform reach.

What Happens Next

This is a pre-PEP—preliminary discussion, not final. The thread on discuss.python.org has 117+ comments. Alex Gaynor, a Rust expert who migrated the cryptography library, offered to help. The proposal has traction, but it’s not a done deal.

If approved, Python 3.15 (2026) is the first checkpoint—warnings if Rust is missing, but builds succeed. That gives a year to test integration and benchmark build times before Python 3.16 makes Rust conditionally required in 2027.

The fundamental question: do memory safety gains justify bootstrap complexity and platform abandonment? Rust eliminates 66% of CVEs but also eliminates support for RISC OS, HP PA-RISC, and Mac OS X PowerPC. The Python community has three years to decide.

Key Takeaways

• CPython core developers Emma Smith and Kirill Podoprigora proposed integrating Rust into Python’s core, with Rust mandatory by Python 3.17 (2028)
• Bootstrap paradox: Rust needs Python to build, but this proposal makes Python need Rust—requiring a three-stage build process
• 11 of 20 officially supported CPython platforms are Tier 3 for Rust; 4 platforms have zero support, risking abandonment
• Memory safety motivation is real: Linux kernel eliminated 66% of CVEs with Rust, and 25-33% of new Python extensions already use it
• Community divided: Guido van Rossum supports it, but core developers worry about build times, maintainer tensions, and cultural clash similar to Linux kernel’s Rust friction