Python 3.15 Release Date Set for October 9: What's New
Python's core team shipped 3.15.0rc3 on October 2 ahead of the October 9 final release, locking in PEP 810 lazy imports, a new frozendict type, and a faster JIT compiler.

Python 3.15.0 is now locked for release on October 9, 2026, after the core team shipped a surprise third release candidate, 3.15.0rc3, on October 2 to fold in a batch of last-minute fixes to the headline lazy-import feature. The final build will ship with explicit lazy imports (PEP 810), a new immutable frozendict type, UTF-8 as the default text encoding everywhere, a faster experimental JIT, and a dedicated statistical profiler capable of sampling at up to 1,000,000 Hz. Here is what changed, why the release slipped by a week, and how to test it before the final drops.
- Final release date: October 9, 2026
- Latest preview: 3.15.0rc3, released October 2, 2026
- Headline feature: PEP 810 explicit lazy imports
- New builtins:
frozendict(PEP 814),sentinel(PEP 661) - Default encoding: UTF-8 everywhere (PEP 686)
- Download: python.org/downloads
Release date and why RC3 happened
Python follows an annual release cadence, and 3.15.0 was originally due to go final the first week of October. Instead, release manager Hugo van Kemenade published a third release candidate on the official Python Insider blog, writing plainly: "We got some last-minute lazy-import release blockers, and it makes sense to include them in 3.15.0 final." Rather than rush a fix into the final tag, the team pushed the finish line back by exactly one week, to October 9, 2026.
RC3 is not a cosmetic update. It bundles roughly 156 bugfixes, build-system tweaks, and documentation corrections contributed by 82 people since RC2 shipped on September 25. The team has also drawn a hard line under the build: there will be no further ABI changes in the 3.15 series from this point on, and the goal for the final week is "as few code changes as possible." That matters for package maintainers, since Python's release notes explicitly promise that "any binary wheels built against Python 3.15.0 release candidates will work with future versions of Python 3.15," so compiled extensions tested now won't need to be rebuilt once the final tag lands.
How to download and test it now
Python 3.15.0rc3 installers for Windows and macOS, along with source tarballs, are posted on the official python.org release page. The core team is explicitly asking library and framework maintainers to install the candidate, run their test suites against it, and publish compatible wheels to PyPI before the 9th, so that the ecosystem isn't caught flat-footed on day one. Anyone hitting a regression is directed to file it against the CPython issue tracker on GitHub rather than waiting for the stable release.
As with every annual Python release, this build is not meant for production workloads. Treat it the way you'd treat any release candidate: fine for CI matrices, virtual environments, and compatibility testing, but not for anything customer-facing until the 3.15.0 final tag is cut on the 9th.
PEP 810: explicit lazy imports
The feature that forced the extra release candidate is also the one most developers will notice first. PEP 810 adds a lazy soft keyword that defers loading a module until the first time something in it is actually used:
| Before (eager import) | After (lazy import) |
|---|---|
import json(loads immediately, every time) | lazy import json(loads only on first use) |
from pathlib import Path | lazy from pathlib import Path |
| No CLI control | -X lazy_imports flag, PYTHON_LAZY_IMPORTS env var |
| n/a | sys.set_lazy_imports_filter() for selective control |
The point is startup time: large applications and CLIs that import dozens of modules they only sometimes need can skip that work entirely on the common path. Lazy-loaded modules are exposed as a new types.LazyImportType, and the exact blockers that triggered RC3 were edge cases in how that deferred loading interacts with existing import machinery, which is why the team wanted an extra week of real-world testing rather than shipping it provisionally.
New builtins: frozendict, sentinel, and comprehension unpacking
Python gets its first built-in immutable mapping type with PEP 814's frozendict. It behaves like a regular dict for reads, preserves insertion order, is hashable when every key and value is hashable, and raises TypeError on any attempt to mutate it in place. It's also wired into copy, json, pickle, and marshal, so it behaves like a first-class citizen of the standard library rather than a bolt-on.
PEP 661 adds a built-in sentinel type for creating unique placeholder values with clean reprs, identity-preserving copies, and optional pickling support — a pattern library authors have hand-rolled for years. PEP 798 extends star-unpacking syntax to comprehensions, so [*row for row in rows] flattens a list of lists and {**d for d in dicts} merges a sequence of dicts in one expression, without a manual itertools.chain call.
UTF-8 as the default encoding everywhere
PEP 686 finishes a multi-release migration: Python 3.15 now uses UTF-8 as its default text encoding regardless of the operating system's locale settings, for file I/O and anywhere else an encoding isn't explicitly named. It's the same UTF-8 mode introduced as an opt-in flag back in Python 3.7, just flipped on by default. Code that depended on the old locale-dependent behavior — most commonly an issue on Windows, where the system default is rarely UTF-8 — can restore it with the PYTHONUTF8=0 environment variable or the -X utf8=0 flag while it's updated.
Performance: a faster JIT and the Tachyon profiler
The experimental JIT compiler introduced in recent Python releases gets a tail-calling interpreter upgrade that the project says meaningfully speeds up 64-bit Windows binaries in this release. On the tooling side, Python 3.15 ships a new dedicated profiling package that reorganizes the ecosystem into profiling.tracing (the deterministic, cProfile-style tracer) and profiling.sampling, home to Tachyon, a new high-frequency statistical sampling profiler.
| Capability | Tachyon sampling profiler |
|---|---|
| Max sampling rate | Up to 1,000,000 Hz |
| Modes | Wall-clock, CPU time, GIL-holding time, exception handling |
| Output formats | pstats, collapsed stacks, flamegraphs, Gecko profiler format, heatmaps, live TUI |
| Can attach to a running process | Yes, by PID, with near-zero overhead |
Being able to attach Tachyon to an already-running production process by PID, with low enough overhead to leave switched on, is a notable step up from the profile-locally-then-deploy workflow most Python teams use today, and it mirrors sampling profilers long available in other language ecosystems. Node.js has leaned on similar always-on tooling in its own recent releases; see our coverage of Node.js 26 LTS and its new yearly release model for a comparable example of a runtime standardizing its release cadence.
Friendlier error messages and more color in the CLI
Python 3.15 extends the "did you mean" suggestions introduced for NameError in earlier versions to AttributeError, including cross-language hints — calling .push() on a list now suggests .append(), and calling a JavaScript- or Java-style method name on a string nudges you toward the Pythonic equivalent. The standard library also adds more ANSI color to CLI output across tools including argparse, difflib, sqlite3's interactive shell, tokenize, and the interpreter's own help system.
Standard library updates and a security fix
Beyond the headline PEPs, Python 3.15 touches dozens of standard-library modules. asyncio.TaskGroup gains a cancel() method for shutting down every task in a group early instead of cancelling them one by one. The math module adds a new math.integer submodule plus isnormal(), issubnormal(), fmax(), fmin(), and signbit(). subprocess moves to event-driven process waiting on Linux 5.3+, macOS (via kqueue), and Windows, which should reduce polling overhead for anything that shells out heavily. tomllib catches up to TOML 1.1.0, and bytearray gets a zero-copy take_bytes() method.
One change is squarely about security rather than convenience: tarfile ships fixes for path-traversal issues and now normalizes symlinks more strictly when extracting archives — the same class of "tar slip" vulnerability that has shown up repeatedly across language ecosystems whenever archive extraction trusts file paths it shouldn't. Anyone who unpacks untrusted tarballs, including in CI pipelines and container build steps, gets safer defaults for free in 3.15.
Typing, free-threading, and the C API
Free-threaded builds — the no-GIL mode Python has been stabilizing since 3.13 — get their own stable ABI in 3.15 under PEP 803, which extends the abi3 promise that lets a single compiled C-extension wheel work across Python versions to free-threaded builds too (abi3t). That's paired with PEP 788, which adds new C API guards so extension authors can protect against interpreter finalization happening mid-operation, a long-standing source of hard-to-reproduce crashes in multi-interpreter and free-threaded code. Neither change is visible to everyday Python code, but both matter if your dependency tree includes NumPy, pandas, or any other package shipping compiled extensions.
On the typing side, PEP 728 lets TypedDict declare the type of extra, unlisted items instead of forcing total=False escape hatches, PEP 747 introduces TypeForm for annotating values that represent types themselves, and PEP 800 formalizes how "disjoint base classes" behave in the type system. None of this changes runtime behavior, but static-typing tools like mypy and pyright will pick up the new constructs as soon as they add 3.15 support.
Deprecations, a GC reversal, and what's going away
Not every change is additive. The profile module is now deprecated and scheduled for removal in Python 3.17, in favor of the new profiling package. The __cached__ module attribute is no longer set (use __spec__.cached instead), and .pth files that contain raw import lines are silently deprecated in favor of the new, safer .start startup configuration files from PEP 829.
The most consequential reversal is under the hood: the incremental garbage collector that Python adopted in 3.14 has been reverted back to the generational collector from 3.13, after it caused memory-pressure problems in production deployments. It's an unusually candid admission from the core team that a recent default needed to be walked back, and it's worth knowing about if you track GC behavior across versions in a long-running service.
Should you upgrade when it ships?
For most application code, Python 3.15.0 should be a low-friction upgrade: there are no breaking ABI changes from RC3 onward, and the UTF-8 and lazy-import changes are both designed to be backward compatible by default, with explicit opt-outs. The bigger decision is timing for teams maintaining compiled extensions or packages with native code, since PyPI wheels built against the release candidates are guaranteed to keep working against the final build and beyond. If your project already ships a version-pinned CI matrix the way most modern repos do, adding a 3.15 job now against RC3 costs little and surfaces lazy-import edge cases before your users do. Projects that build inside containers should also note Python 3.15 is already available in preview on Azure App Service for Linux alongside .NET 11 and Node.js 26, so cloud compatibility testing can start immediately rather than waiting for general availability.
Editors and IDEs are also catching up: Visual Studio Code's Python tooling and other editor integrations typically add full syntax support for new soft keywords like lazy within the first few point releases after a Python version ships, so expect minor friction in editor highlighting before that settles — a pattern familiar to anyone who tracked VS Code's own recent 1.140 update catching up to a fast-moving ecosystem.
What's next
Assuming no further blockers surface during RC3 testing, Python 3.15.0 final ships October 9, 2026, with 3.15.1 and other bugfix releases to follow on the usual maintenance schedule over the next two years. The Python Language Summit held in late September at EuroPython already previewed what's likely coming in 3.16 and beyond, including continued free-threading work and a possible one-time ABI break discussed in the summit's lightning talks — topics the core team will firm up over the next release cycle. For now, the practical step is simple: grab 3.15.0rc3, point a CI job at it, and see what breaks before the final tag locks everything in place.
Frequently asked questions
When does Python 3.15 come out?
Python 3.15.0 final is scheduled for October 9, 2026. The last preview build, 3.15.0rc3, shipped October 2, 2026, after the core team added a week-long delay to fix last-minute lazy-import bugs.
What is the biggest new feature in Python 3.15?
PEP 810's explicit lazy imports, which let code defer loading a module with a new `lazy import` keyword until it's actually used, cutting startup time for apps that import more than they need on every run.
Is Python 3.15 safe to use in production right now?
Not yet. 3.15.0rc3 is a release candidate meant for testing, CI pipelines, and compatibility checks. Production use should wait for the 3.15.0 final tag on October 9, 2026.
What is frozendict in Python 3.15?
frozendict, added by PEP 814, is Python's first built-in immutable dictionary type. It behaves like a regular dict for reads, is hashable when its contents are hashable, and raises a TypeError on any attempted mutation.
Did Python 3.15 change the default garbage collector?
Yes. Python 3.15 reverts to the generational garbage collector used in 3.13, after the incremental collector introduced in 3.14 caused memory-pressure problems in production deployments.
Why did Python 3.15 need a third release candidate?
The core team found last-minute blockers in the new lazy-import feature and decided to fix them before the final release rather than patch them afterward, pushing the final date back one week to October 9.
Sources
- Python Insider Blog: Python 3.15.0 candidate 3 is here!blog.python.org
- Python.org: Python 3.15.0rc3 release pagepython.org
- Python Docs: What's New in Python 3.15docs.python.org
- CPython issue tracker on GitHubgithub.com
Felix Moreau writes Pandromeda's software coverage and how-to guides. He covers Windows, macOS and Linux updates, the apps people rely on, emulators and developer tools, and turns official documentation into clear, numbered steps that work on the current version.


