Python 3.15 RC3 Delays Final Release Over Lazy Import Fixes
Python 3.15.0rc3 adds a final testing cycle after lazy-import issues delayed the stable release to October 9. Here is what developers should test before upgrading.
On this page
Python 3.15 will arrive later than originally planned after the core team found last-minute problems around its new lazy-import system. Python 3.15.0rc3, released on October 2, is the final planned release candidate, and the stable release is now scheduled for October 9.
Python 3.15 now has one more release candidate to test
The extra release candidate is not a routine refresh. The Python team said it was added because of last-minute lazy-import release blockers, giving developers and library maintainers another chance to expose problems before the stable branch is finalized. The release contains about 156 bug fixes, build improvements and documentation changes from the previous candidate, with contributions from 82 people.
The timing matters because Python 3.15 is already in the release-candidate phase. At this point, the project allows only reviewed changes that are clear bug fixes, so the feature set is effectively frozen. The team also says there should be no further application binary interface changes from this point forward, reducing the risk for projects that are testing native extensions against the upcoming version.
Why lazy imports caused the delay
Python normally loads an imported module when the import statement runs. That means a command-line application can spend startup time finding modules, loading their code and executing top-level initialization even when the user never reaches the feature that needs them. Python 3.15 introduces explicit lazy imports through the new lazy soft keyword, allowing a module to remain unloaded until the imported name is actually used.
For example, lazy import json keeps the normal import declaration at module scope but postpones loading the module. The cost has not disappeared; it has moved from application startup to the first operation that needs json. That distinction matters for command-line programs and applications with large dependency trees, where delaying unused imports can improve the time before the interface becomes responsive.
Lazy imports are deliberately opt-in
Installing Python 3.15 does not suddenly make every existing import lazy. Normal import statements retain their eager behavior unless developers explicitly mark them as lazy or enable one of the process-wide mechanisms provided by the interpreter. Python also provides -X lazy_imports, the PYTHON_LAZY_IMPORTS environment variable and runtime controls for applications that need broader control.
This is an important compatibility boundary. Existing applications can move to Python 3.15 without automatically changing when their modules execute, while developers can introduce lazy loading selectively in areas where startup cost is measurable. The design also keeps the decision close to the import itself instead of silently changing the behavior of an entire dependency tree.
The new syntax changes when failures appear
There is a trade-off that developers need to test rather than assume away. With an ordinary import, an import failure happens at the import statement. With a lazy import, the failure can be deferred until the imported name is first accessed. The same applies to import-time side effects, so code that relies on a module registering something merely because it was imported needs particular attention before adopting the feature.
Python therefore restricts where lazy imports can be used. The lazy form is available at module scope, while imports inside functions, classes and try blocks cannot use it. Star imports and future imports are also excluded, preserving cases where the timing and semantics of the import operation are especially significant.
Python 3.15 brings more than faster startup
Lazy imports are only one part of the release. Python 3.15 also adds frozendict, an immutable dictionary type, and sentinel, a built-in type for representing unique sentinel values. The release also adds unpacking inside comprehensions, changes the default text encoding to UTF-8, and introduces the Tachyon high-frequency statistical sampling profiler.
The experimental just-in-time compiler has also received substantial work. The Python team reports a 7–8% geometric-mean performance improvement on x86-64 Linux compared with the standard interpreter and an 11–12% improvement on AArch64 macOS compared with the tail-calling interpreter. Those figures are measurements of the experimental JIT configurations described by the Python project, not a promise that every Python program will run that much faster.
Python 3.15 is close enough for compatibility testing
The extra release candidate changes the sensible testing point for maintainers. Python 3.15.0rc3 is intended to be the final planned candidate, and the project says the next release is scheduled for October 9. That gives package authors only a short window to run their test suites, build wheels and investigate behavior that differs from Python 3.14.
Developers should pay particular attention to projects with large import graphs, native extensions, plugin systems or code that depends on import-time registration. Those are the areas where Python 3.15's new mechanisms can expose assumptions that ordinary feature testing may miss. For applications that do not use the new facilities, the conservative approach is simpler: test the new interpreter first, then adopt individual 3.15 features only when they solve a measured problem.
The October 9 release is the next checkpoint
Python 3.15 is now close enough that the major question is no longer what features will make the release, but whether the remaining compatibility and implementation issues are resolved cleanly. The surprise RC3 shows that even a feature-frozen release can require another testing cycle when a change touches the interpreter's import machinery.
For most developers, October 9 is therefore the date to watch rather than a date to rush toward. The useful preparation is to run existing projects against the release candidate, identify import-time assumptions, and decide where the new lazy-import mechanism is actually worth adopting once Python 3.15 becomes stable.
Written by


