Python 3.15.0rc1 was released on August 4, 2026, starting the release-candidate phase for the next CPython series. The release is aimed at maintainers and developers who need to test applications, extension modules, build systems, and CI pipelines before the planned final release.
There is an important status update, however: rc1 is no longer the newest candidate. Python 3.15.0rc2 was released on September 1, 2026. Python 3.15.0rc3 was released on October 2, 2026, after last-minute lazy-import fixes, and the project describes rc3 as the final planned release candidate. The October 1 final was postponed. Python 3.15.0 final is scheduled for October 9, 2026.
What changed in the release-candidate phase
Python 3.15.0rc1 was the first release candidate. During this stage, the project permits reviewed changes that are clear bug fixes, and no further ABI changes are expected in the Python 3.15 series. That makes the candidate window useful for compatibility testing, although neither rc1, rc2, nor rc3 should be treated as a production recommendation.
The rc1 release page provides source archives, macOS and Windows installers, embeddable Windows packages, Android packages, an iOS XCframework, release manifests, checksums, Sigstore metadata, and selected software bill of materials links. The listed macOS installer supports macOS 10.15 and later. Windows artifacts include 64-bit and 32-bit installers, along with an experimental ARM64 installer.
Since rc1, the project has published rc2 with approximately 144 bug fixes, build improvements, and documentation changes contributed by 76 people. The rc2 release page and the official changelog document changes across security, library, core, build, and free-threading areas. Those rc2 changes should not be retroactively presented as characteristics of rc1. On October 2, 2026, the project published rc3, with about 156 bug fixes, build improvements, and documentation changes from 82 contributors since rc2. The rc3 release page calls that candidate the final planned release candidate.
Free-threaded extension support gets an ABI direction
One of the practical areas for extension maintainers is the stable ABI for free-threaded builds, called abi3t. According to the abi3t migration documentation, an extension using this ABI can support both free-threaded and non-free-threaded builds, provided it makes the required C API changes and completes the necessary testing.
The documentation also describes abi3.abi3t wheel tagging. This may allow some projects to reduce the number of separate extension artifacts they need to publish, but it is not an automatic compatibility switch. Maintainers still need to review the documented C API requirements and test every supported CPython version in both free-threaded and non-free-threaded modes.
The official macOS documentation says that supported installers provide universal2 binaries for Intel and Apple Silicon Macs. The installers are signed and notarized, require administrator privileges, and install the optional free-threaded feature by default. After installation, macOS users are instructed to run Install Certificates.command. The documentation also describes options for installing and testing free-threaded and traditional interpreters.
Tachyon adds operational sampling options
Python 3.15 documentation includes the Tachyon profiler through the profiling.sampling module. The tool can run a script, profile a module, attach to a running process by PID, dump a single stack snapshot, and produce flame graphs or heatmaps. It also supports live operation and configurable output formats, duration, and sampling rate.
Example invocations documented by Python include:
python -m profiling.sampling run script.py
python -m profiling.sampling attach PID
python -m profiling.sampling dump PIDTachyon uses statistical stack sampling. Its time values are therefore estimates rather than direct measurements. The documentation cautions that short-lived programs and investigations requiring exact call counts may need other tools. Attaching to a process is an operational capability, not a security guarantee; teams should apply their normal access controls and operational policies.
Build and installation considerations
Developers building CPython from source need a C11 compiler, IEEE 754 floating-point and NaN support, and thread support. Windows source builds require Microsoft Visual Studio 2017 or later. The usual source-build flow uses ./configure followed by make, while the official configure documentation lists build options and dependencies.
Optional standard-library modules can require additional development libraries. The documented examples include OpenSSL, SQLite, Tcl/Tk, zlib, libbz2, libffi, liblzma, libmpdec, readline or libedit, libuuid, ncurses, and zstd. A successful base build does not necessarily mean every optional module will be available, so maintainers should check the resulting build when validating a platform configuration.
The release pages provide artifacts and verification metadata, but the supplied documentation does not amount to one complete end-user installation procedure for every Linux, Windows, macOS, Android, or iOS scenario. Teams should use the artifact appropriate to their platform and consult the corresponding official documentation rather than assuming that one installation path applies everywhere.
What developers and administrators should do
- Test application compatibility. Run representative test suites against the current Python 3.15 release candidate and record failures separately from issues caused by the candidate environment.
- Validate extension builds. C-extension maintainers should test supported CPython versions and both free-threaded and non-free-threaded interpreters. Projects considering
abi3tshould review the migration requirements before changing their wheel strategy. - Exercise CI and packaging workflows. Confirm that build images, interpreter discovery, dependency installation, wheel selection, and test matrices behave as expected. The supplied documentation explains ABI and testing requirements but does not provide a complete end-to-end wheel publishing workflow.
- Check platform-specific artifacts. Use the release page’s checksums and available Sigstore or SBOM metadata as entry points for artifact verification. On macOS, account for the installer requirements and certificate-installation step.
- Use profiling carefully. Tachyon can help investigate sampling-based performance behavior and running processes, but its results are estimates and should not be treated as exact call counts or precise microbenchmark measurements.
- Report release issues. Problems found during candidate testing should be reported through the CPython bug tracker referenced by the official release pages.
Availability and release timing
Python 3.15.0rc1 remains available from the official release page, but it has been superseded by rc2 and rc3. The project describes rc3, released October 2, 2026, as the final planned release candidate. Python 3.15.0 final is scheduled for October 9, 2026. That date is a schedule, not confirmation that the final build is already available.
The candidate status also matters for security interpretation. The rc2 changelog includes entries such as CVE-2026-15806 and fixes affecting archive extraction and decompression behavior, but those entries are rc2 changes and should be attributed to rc2. The available material does not establish a security characterization for rc1, free-threading, Tachyon, or frame-pointer-related behavior.
For maintainers, the immediate value of the release-candidate window is compatibility evidence. Testing now can expose interpreter, extension, packaging, and CI issues before the scheduled final release, while the expected ABI stability provides a clearer target for final validation.
Sources
- Python Insider: Python 3.15.0 candidate 1
- Python 3.15.0rc1 release page
- Python 3.15.0rc2 release page
- Python 3.15.0rc3 release page
- PEP 790: Python 3.15 release schedule
- What’s New in Python 3.15
- Migrating C extensions to the free-threaded stable ABI
- Tachyon sampling profiler documentation
- Using Python on macOS
- CPython configure and build requirements
- Python changelog
