RustConf Talk Details CPython's Narrowed Plan for an Optional Rust API in Python 3.16
At RustConf in Montreal, Rust's programming manager outlined CPython's scaled-back plan to add an optional internal Rust API in Python 3.16, along with unresolved technical hurdles.
Editor's Note ·
- Correction:
- The article states that Emma Smith posted an update narrowing the pre-PEP's scope to optional-only Rust modules "within a day" of her original November 2025 post, quoting that update directly. The cited discuss.python.org thread does not corroborate this timing, and The Register -- the article's own primary source -- states the scope was narrowed "in May" (2026), several months after the original post, not the next day. The underlying fact that the pre-PEP was eventually narrowed to optional-only modules, with the required-dependency question deferred to a future PEP, is accurate and independently corroborated; only the "within a day"/November 2025 timing of that update is incorrect.
Overview
At RustConf in Montreal last week, Rust Programming Manager Tomáš Šedovič gave the most detailed public update yet on how the Python and Rust projects are working together to bring Rust into CPython, Python’s reference interpreter, according to The Register. The current approach, he said, “sidesteps a lot of the concerns that people brought up” during the debate over whether Rust should become a required dependency of CPython, The Register reported.
What We Know
CPython core developer Emma Smith first proposed incorporating Rust into the project in a pre-PEP posted to Python’s discussion forum in November 2025, initially aiming to make Rust a required dependency across the codebase, as previously reported by The Machine Herald. Within a day, Smith posted an update narrowing that scope: “We’ve decided to re-focus the (pre-)PEP to only propose the introduction of optional Rust extension modules to CPython,” she wrote in the same thread, adding that extending Rust to “the required modules and the interpreter core itself” would be left to “a future PEP.”
Python creator Guido van Rossum endorsed the plan in that thread, writing: “We all know that a full rewrite in Rust won’t work, but starting to introduce Rust initially for less-essential components, and then gradually letting it take over more essential components sounds like a good plan.”
Šedovič’s RustConf talk described where that work stands now. An internal Rust API is planned for the Python 3.16 release, according to The Register, which is scheduled to reach its final build on October 5, 2027, according to Python’s official 3.16 release-schedule document. The plan also calls for including a Rust implementation of the zlib compression library as the API’s first test crate, The Register reported.
Technical Hurdles
Several integration problems remain unresolved, according to The Register’s account of the talk. Rust currently lacks support for GCC, the GNU Compiler Collection, which CPython needs because of the “long tail” of unusual platforms it supports. The two languages also differ in how they build standard libraries and individual dynamic shared libraries, differences that still need to be reconciled. Python will also need some form of cross-language “sanitizer” to catch unsafe memory states arising where the two languages’ memory models meet; The Register noted that a project called BorrowSanitizer is already working on a similar problem for C and C++ code that links against Rust.
The most difficult piece, per Šedovič, will be extending Rust’s Drop trait — the language’s mechanism for running cleanup code when a value goes out of scope — so that Python objects can receive runtime context when they are deallocated. He called it a challenge that “will take some major think-em-ups from Rust engineers.”
The influence runs in both directions. The original pre-PEP praised Cargo, Rust’s build tool, as “an excellent build system” that handles dependency acquisition, compiling, linking and testing in one tool. Python has already moved toward that model with uv, described in its own documentation as “an extremely fast Python package and project manager, written in Rust.” The Register reported that Van Rossum joked CPython might eventually need to be renamed “CRPython.”
What We Don’t Know
Neither the RustConf talk nor the pre-PEP thread has specified which standard-library module will be the first candidate for an official Rust implementation once the internal API lands, and no timeline has been set for the separate, future PEP that would extend Rust to CPython’s required modules or interpreter core — the piece Smith deferred in November.
Analysis
The RustConf update points to CPython’s Rust integration proceeding on a narrower, slower path than first floated: an optional, internal API confined to non-essential components, arriving alongside the language’s next major version rather than ahead of it. That caution tracks with The Machine Herald’s earlier coverage of the project’s retreat from a hard, multi-year Rust requirement, and it leaves open questions about GCC support and cross-language memory safety that will need answers before Rust moves beyond a single test crate inside one of the world’s most widely used programming language implementations.