The Rust for CPython project has moved beyond planning toward a working reference implementation. Its CPython fork builds with Rust in continuous integration on tested platforms, while a separate zlib-py repository demonstrates how a Rust extension can expose functionality to Python through PyO3.
That progress does not mean Rust is now part of a released CPython version. The project has shifted its first intended Rust code from Python 3.15 to Python 3.16, and it still needs further API design, a PEP, and an integration decision. For most Python developers, the immediate impact is limited: this is an experimental project to evaluate and contribute to, not a new production requirement.
What changed in the Rust for CPython project
According to the April 2026 progress update and its accompanying Python discussion, the project now has a fork that builds CPython with Rust in CI across the platforms it currently tests. This is an important implementation milestone because it demonstrates that Rust can participate in the CPython build process within the project’s current reference setup.
The project is also developing an internal Rust API. That API is intended to remain internal while the design evolves. The project expects a later PEP to define and stabilize any public interface, so developers should not treat the current API as a supported extension framework.
The schedule has also changed. The project originally aimed at Python 3.15 for its first intended Rust code, but now targets Python 3.16. The roadmap described in the update includes choosing an extension module, developing the internal API, drafting a PEP, and submitting that proposal for discussion.
What the zlib-py proof of concept shows
The most concrete standalone example is the zlib-py repository. It is a small proof of concept that uses PyO3 to expose zlib-rs functionality to Python. PyO3 is the Rust project used here to connect Rust code with Python-facing extension functionality.
zlib-py is useful as an implementation example, but it should not be confused with a confirmed CPython feature. The available information does not establish that zlib is the extension module ultimately selected for Python 3.16 integration. It demonstrates a possible direction rather than a final component choice.
The repository documents both Nix and non-Nix workflows. The Nix examples include nix build, nix run .#python, and nix develop. The non-Nix workflow uses uv sync, uv run maturin develop, and Python launched through uv. The Nix setup uses pinned CPython and PyO3 revisions and an offline, vendored Cargo registry, according to the repository documentation.
Those commands describe the proof of concept, not mandatory requirements for all Rust-for-CPython development. In particular, the repository warns that its resolved non-Nix CPython and PyO3 environment is not guaranteed to work. The complete supported-platform and dependency matrix for the broader project remains undocumented.
Build and toolchain details remain experimental
The Rust workspace in the CPython fork specifies rust-version = 1.95. Its workspace includes Rust-related components for _base64, a CPython build helper, a Rust static library, and CPython system interfaces. These details confirm that the reference implementation has a structured Rust workspace, but they do not define a stable developer contract.
Extension authors should therefore avoid changing production build pipelines based on this project alone. There is no verified announcement that existing Python extensions must be rewritten, that current binary compatibility rules have changed, or that package maintainers need to add Rust to their release environments.
Performance results are limited to the proof of concept
The zlib-py repository includes sample benchmark comparisons from Darwin arm64 using CPython 3.16.0a0. Several operations were faster in the documented results, while crc32 was slower. The repository also reports output differences at intermediate compression levels.
These observations are valuable because they show why each operation and environment must be evaluated separately. They are not general conclusions about Rust performance, zlib compatibility, or the behavior of a future CPython release. The results come from a specific proof-of-concept environment and should not be used as a production performance forecast.
What Python 3.16 means for the timeline
The project’s revised target is Python 3.16, but target status is not release confirmation. The official Python 3.16 schedule places development start on May 7, 2026 and beta 1, along with the feature freeze, on May 4, 2027. No new features are permitted after beta 1.
That schedule gives the project a reference point for API work, PEP discussion, and any potential integration decision. It does not establish that a PEP has been accepted or that Python 3.16 will ship Rust code. The project’s acceptance criteria, final API design, packaging requirements, and production-readiness standard remain unresolved.
Practical implications for developers and administrators
- Application developers: No action is required for ordinary Python applications based on the available information. Rust integration is not documented as a generally available feature in a released CPython version.
- Extension authors: Do not assume that existing extension interfaces, build systems, packaging workflows, or binary compatibility guarantees will remain unchanged. The internal Rust API is not public or stable.
- Build and platform teams: Treat the zlib-py workflows as experimental examples. The documented Rust 1.95 workspace requirement applies to the reference workspace, not automatically to every CPython or extension build.
- Performance engineers: Reproduce measurements in the relevant interpreter and target environment before drawing conclusions. The available zlib-py results include both improvements and a regression, as well as output differences.
- Potential contributors: The project invites participation through its Discord community and stated Monday meetings at 12:00 PM PDT. Contributors can also provide input on the internal API design through the project’s contribution channels.
What you should do now
- Continue using released CPython and your existing extension toolchain unless you are intentionally evaluating the experimental reference implementation.
- If you test zlib-py, isolate it from production environments and record the interpreter, operating system, architecture, compiler, and dependency setup used for each result.
- Review the project’s API discussions before building integrations around its internal Rust interfaces.
- Follow the PEP and Python 3.16 schedule for decisions about public APIs and possible inclusion rather than treating the current fork as a committed feature.
Availability and remaining limitations
Rust support is currently evidenced by a project fork, CI builds, and a proof-of-concept repository. It is not presented as a generally available capability in a released CPython version. The internal API is not stable, the PEP has not been established as accepted, and the project roadmap can change.
Rust adoption should also not be treated as an automatic security guarantee. The supplied project information does not characterize this work as a security fix, vulnerability mitigation, or security feature.
