Python 3.15 ships lazy imports, an upgraded JIT and free-threading support

Release manager Hugo van Kemenade oversaw a 5,643-commit cycle that also makes UTF-8 the default encoding and adds new profiling tools.

By · Published

Primary source: Python.org

Why it matters

Python 3.15 pushes runtime efficiency, free-threading and observability forward without requiring teams to abandon existing Python code. The payoff depends on real-world package compatibility and workload testing, especially for the experimental JIT and native extensions.

Python 3.15 ships lazy imports, an upgraded JIT and free-threading support — Release manager Hugo van Kemenade oversaw a 5,643-commit cycle that also makes UTF-8 the default encoding and adds new profiling tools.

Python 3.15.0, released on October 9th, gives developers new ways to reduce import work, test free-threaded builds and profile applications, while advancing an experimental just-in-time compiler. The official release page lists 5,643 commits from 1,012 contributors across the cycle.

Hugo van Kemenade, Python 3.15's release manager, coordinated the final release with Windows installer lead Steve Dower and macOS installer lead Ned Deily. The release schedule also assigns documentation work to Julien Palard. Van Kemenade thanked the Sovereign Tech Agency for supporting his work on Python 3.14 and 3.15 through its Sovereign Tech Fellowship.

The release is a community-built update to CPython, Python's reference implementation, rather than a commercial product from a venture-backed company. Its practical bet is that developers can get useful runtime and tooling improvements while keeping the language and its existing codebases. The features land together, but their value will depend on application workloads, operating systems and the third-party packages those applications rely on.

The performance work is still a test, not a promise

The most prominent performance claim concerns Python's experimental JIT compiler. The release page reports a 7% to 8% geometric-mean improvement on x86-64 Linux against the standard interpreter, and an 11% to 12% speedup on AArch64 macOS against the tail-calling interpreter. Those results use different platforms and baselines; they are not a single cross-platform comparison or a guarantee for every Python application. The Python 3.15 documentation describes the JIT as experimental and details the broader work behind the upgrade.

A numerical table lists Python 3.15's reported experimental JIT results: 7% to 8% geometric-mean improvement on x86-64 Linux versus the standard interpreter, and 11% to 12% speedup on AArch64 macOS versus the tail-calling interpreter.
The Python 3.15 release page reports results under different platform and interpreter-baseline conditions; the figures are not a cross-platform comparison — AI explanatory infographic, not documentary evidence. RuntimeWire · AI-generated infographic.

For many application teams, the more immediately testable change may be explicit lazy imports. Python can defer loading a module until its imported name is first used, an option aimed at reducing the startup cost of code that imports large dependency trees. Developers have long worked around import overhead by moving imports into functions or loading modules on demand. The new syntax offers a built-in alternative, though teams will still need to test how deferred loading interacts with their own startup paths and error handling.

Python 3.15 also makes UTF-8 the default encoding, adds built-in sentinel and frozendict types, and allows unpacking in comprehensions. These changes touch common language and runtime behavior, with implications for code that depends on the old default encoding or maintains its own sentinel and immutable-mapping patterns. The release's porting notes are the place to check before moving production services.

Free-threading reaches the release tooling

The macOS binaries now install free-threading support by default, and Python 3.15 adds a stable ABI path for extensions built for free-threaded CPython. That work addresses a practical obstacle for teams exploring parallel execution: native extensions must be built and supported for the relevant interpreter mode. A stable ABI can reduce some version-specific build burdens, but it does not make every extension compatible automatically. Teams should verify the status of their dependencies and measure their own workloads before treating free-threading as a drop-in speedup.

Other infrastructure changes aim to make Python easier to inspect and maintain. Frame pointers are enabled by default to improve system-level observability, and the standard library gains a dedicated profiling package that includes Tachyon, a high-frequency statistical sampling profiler. The official Windows 64-bit binaries also use a tail-calling interpreter. These are changes aimed at people running and diagnosing software, alongside the syntax additions that are easier to spot in a release summary.

Van Kemenade's announcement also points to a release-day project from core developer Barry Warsaw: whatsnewt, a text-adventure game that has players solve puzzles by using Python 3.15 features in a Python 3.15 interpreter. Warsaw contributed the new package startup configuration files, a feature designed to make executable startup configuration easier to audit than executable lines in .pth files. The game is a playful tour, while the underlying change addresses code that can run automatically during interpreter startup.

Upgrading still means checking the edges

Python's own release notes flag a macOS 27.0 issue affecting IDLE and other Tk-based applications: opening certain menu dialogs can make them hang. The notice attributes the problem to an operating-system behavior change believed to affect current Tk versions and Python versions, rather than to a new defect specific to 3.15. Teams that depend on Tk applications should test that workflow before upgrading macOS.

The Python 3.15 release schedule identifies van Kemenade as release manager, placing this release at the end of a planned development cycle that included alpha, beta and release-candidate testing. The official release page credits the contributor count, but those totals do not establish how quickly package maintainers will support the new version or how much speed an individual service will gain. For engineering teams, the decision remains a familiar one: test the new runtime against actual dependencies and workloads, then move when the compatibility and operational case is clear.

Reader comments

Conversation for this story loads after sign-in.