Python 3.15 Release Date Delayed: What Developers Need to Test Now

Python 3.15 will not arrive on its originally planned October 1 date after the project shipped an unexpected third release candidate on October 2. The new Python 3.15 release date is October 9, giving developers one more week to test changes tied to lazy imports and the final release process. This is more than a schedule adjustment: Python 3.15 contains changes to imports, text encoding, the just-in-time compiler, free-threaded builds and the C application programming interface that extension authors should test before upgrading.

Python 3.15 gets a surprise RC3 because lazy imports needed more testing

Python's release team originally expected the final 3.15 release on October 1, but last-minute blockers around lazy imports changed that plan. Python 3.15.0rc3, released October 2, is now described as the final planned release candidate and contains roughly 156 bug fixes, build improvements and documentation changes since release candidate 2. The additional candidate gives the project time to test the import changes before the final build rather than pushing a known unresolved issue into a stable release. The final Python 3.15.0 release is now scheduled for October 9.

A release candidate is the stage where a project considers the software nearly ready for production and generally restricts changes to reviewed fixes. Python's release notes say there will be no application binary interface, or ABI, changes from this point forward in the 3.15 series. That matters to developers who maintain compiled extensions because the ABI defines how compiled Python modules interact with the interpreter. The extra week therefore gives application and package maintainers a final window to test compatibility without expecting the underlying interface to keep moving.

Python 3.15's biggest developer-facing change is explicit lazy imports

Python 3.15 introduces explicit lazy imports, allowing developers to write an import that does not load its target module until the imported name is actually used. A normal statement such as import json loads the module immediately, while the new lazy import json form defers that work. The distinction is useful for applications with large dependency trees because a command can avoid loading modules belonging to features that the user never invokes. Crucially, the feature is opt-in, so existing ordinary imports continue to behave eagerly.

The practical benefit is startup work rather than a promise that every Python application will suddenly run faster. Python's proposal says lazy imports can reduce startup time substantially in workloads dominated by unnecessary imports, while also reducing memory use by keeping unused modules unloaded. But there is a trade-off: import-time errors and module-level side effects can move from application startup to the first point where the lazy module is accessed. That means a library that registers plugins, configures global state or performs other work during import needs deliberate testing before its imports are made lazy.

The new import syntax is deliberately safer than making every import lazy

Python's design avoids silently changing the meaning of existing programs. The lazy keyword is a context-sensitive keyword that only applies to import statements, and lazy imports are normally enabled only where developers explicitly request them. Python also provides a __lazy_modules__ mechanism that can help libraries maintain compatibility with older Python versions while adopting the feature in 3.15 and later. This gives maintainers a gradual migration path instead of forcing an entire dependency tree to change its import timing at once.

That restraint is significant because import timing is part of how many Python applications behave even when developers do not think of it as an API. A module may populate a registry, validate configuration or raise an exception during import, and moving that action later can change application behavior. Python's own guidance therefore recommends identifying slow imports first and testing side effects rather than applying lazy loading indiscriminately. The feature is best understood as a performance tool for selected imports, not a switch that should be turned on across an entire project without investigation.

Python 3.15 also changes the default encoding developers should expect

Python 3.15 makes UTF-8 the default text encoding when code does not explicitly specify an encoding. UTF-8 is the Unicode encoding used by most modern web and software systems, but older Python programs can still depend on the operating system's locale-specific default. The change means code such as open("data.txt") will use UTF-8 when no encoding argument is supplied instead of inheriting the platform's locale encoding.

For most modern applications, this should reduce differences between machines rather than create them. The risk is in older programs that read or write files produced with a different legacy encoding and rely on the host system to select it automatically. Developers maintaining those applications should test representative files instead of assuming that a successful startup means the migration is safe. Where the file format has a defined encoding, specifying it explicitly remains the clearest option.

The free-threaded build gets a more important ABI story in 3.15

Python's free-threaded build is the version of CPython designed to run without the traditional Global Interpreter Lock, allowing certain Python threads to execute Python code concurrently. Python 3.15 adds Stable ABI support for free-threaded builds, an important change for developers who distribute compiled extension modules. The Stable ABI is the compatibility interface intended to let extensions work across Python releases without rebuilding for every interpreter version, and the new work addresses a gap that previously made free-threaded builds harder to support through the stable interface.

This does not mean every existing C or C++ extension automatically becomes compatible with free-threaded Python. Extension authors still need to use the appropriate APIs and build targets, and the PEP describing the work calls for migration to APIs needed for the new ABI. For projects that distribute binary wheels, this is one of the areas worth testing against the release candidate now because compatibility problems can appear below the Python source-code level.

The upgraded JIT matters, but Python 3.15 is not just a speed release

Python 3.15 also contains a substantially upgraded experimental just-in-time, or JIT, compiler. A JIT compiler can translate frequently executed Python operations into machine code while a program is running, potentially reducing the interpreter work needed for hot code paths. Earlier Python 3.15 development releases reported geometric-mean performance improvements from the JIT on specific x86-64 Linux and AArch64 macOS test configurations, but those figures came from the project's own development benchmarks and should not be treated as a universal application speedup.

The more useful way to read the JIT work is that Python is continuing to improve execution performance without requiring ordinary developers to rewrite applications around a new programming model. Python 3.15 also includes a new profiling package, a built-in immutable dictionary type called frozendict, unpacking in comprehensions and improvements to error messages. Taken together, the release is broader than a single performance feature, with changes spread across the language, interpreter, standard library and extension interface.

Python 3.15 developers should test these areas before October 9

The extra release candidate creates a useful final testing window for package maintainers. Pure-Python projects should first run their existing test suites on Python 3.15.0rc3, paying particular attention to code that reads files without an explicit encoding or relies on import-time behavior. Projects using lazy imports should test both the first access to each deferred module and failure paths, because errors that previously happened during startup can now happen later. Maintainers of binary packages should also test their wheels against the 3.15 ABI changes, especially if they support free-threaded Python.

Python's release team is specifically asking third-party maintainers to prepare for 3.15 and publish compatible wheels on the Python Package Index before the final release. The project says wheels built against the 3.15 release candidates will work with later Python 3.15 versions, which makes the current candidate useful for ecosystem testing rather than merely a preview for individual developers. Production deployments should still wait for the final release because the project explicitly labels the release candidate as a preview.

The October 9 release is now the date package maintainers should work toward

Python 3.15.0rc3 has effectively moved the project into its final testing stretch. The new October 9 date gives developers one additional week to find problems before the stable build, while the feature set is already defined closely enough for application and library compatibility work to begin in earnest. The most consequential tests are not likely to be simple syntax checks; they are the places where import timing, file encoding, compiled extensions and free-threaded builds intersect with existing assumptions.

For developers maintaining ordinary Python applications, there is no reason to rewrite code simply because 3.15 is arriving. The sensible first move is to run the existing test suite on the release candidate, identify failures, and then adopt individual 3.15 features where they solve a measured problem. For library and extension maintainers, the deadline is more concrete: test wheels, check C API compatibility and make sure dependencies are ready before Python 3.15 becomes the stable interpreter on October 9.