Python 3.15 Ships This Friday. Here's What Actually Matters.

Python's release team did something unusual last week: they delayed the final. The plan was to ship 3.15.0 on October 1; instead, last-minute lazy-import blockers forced a surprise third release candidate. The new date is October 9 — five days from now. After 156 bugfixes from 82 contributors since rc2, an ABI freeze, and one of the most carefully watched feature lists in recent memory, this is the last preview before the real thing.

I've spent the week reading the release notes, the PEPs, and the hands-on reports from people already testing rc3. Here's the honest version: what 3.15 changes, what might bite you, and what to do before Friday.

Lazy imports: the headline, and the reason we're on rc3

PEP 810 gives Python explicit lazy imports: you can mark an import as deferred, and it only executes when the name is first used. For large applications — a CLI tool or a serverless function that imports a framework, an ORM, and a dozen helpers just to handle one request — this cuts startup time dramatically. The release team reports up to 70% faster startups on large codebases like Meta's.

What makes this interesting is that it's opt-in, not magic. Python's history with implicit laziness taught the core team that hidden behavior creates hidden bugs. So lazy import says exactly what it means, and tooling can see it coming.

The other thing worth knowing: lazy imports are why we have an rc3 at all. The late blockers were lazy-import bugs found after rc2 — which tells you this is the highest-risk new feature in the release, and the one most worth exercising in your own test suite this week.

Two new builtins you'll actually use

3.15 adds two built-in types that solve problems every working developer has tripped over.

frozendict (PEP 814) is the immutable counterpart to dict — hashable, fixed at creation, and safe to use as a dictionary key or a shared default. The use case is obvious once you see it: configuration objects that should never change, caches keyed by frozen mappings, and APIs that hand out "read this but don't touch it" data. Previously you reached for types.MappingProxyType, which wraps a dict but never quite felt like a first-class citizen. Now it's a builtin.

sentinel (PEP 661) kills the _MISSING = object() pattern. Every library author has written that line, and every one of them has stared at <object object at 0x7f...> in a traceback. The new sentinel() creates named, repr-friendly singletons that are cheap to create and impossible to collide with. Small change; it removes an entire class of debugging annoyance.

Rounding out the quality-of-life list: unpacking inside comprehensions (PEP 798), and colored help text and CLI output — because even core developers have eyes.

The quiet behavior change: UTF-8 by default

PEP 686 makes UTF-8 Python's default preferred encoding, which means open() without an encoding= argument now decodes as UTF-8 regardless of the system locale. For most modern code this changes nothing visible — UTF-8 was already what you got on most systems. But if any of your pipelines, log parsers, or ETL scripts rely on the ambient locale to read legacy-encoded files, the behavior shifts silently.

The fix is mechanical and worth doing this week: grep your codebase for bare open() calls and add explicit encoding= where the input isn't guaranteed UTF-8. That's the kind of change that never makes the announcement but always makes the postmortem.

In the same spirit, 3.15 finally removes a few long-deprecated leftovers: the internal regex modules (sre_compile, sre_constants, sre_parse) and http.server's CGI handler. If your code imports them, you were already on borrowed time.

Faster — in increments that add up

There's no single performance headline this cycle, which is arguably the point. The JIT compiler gets a solid upgrade: an 8–9% geometric-mean improvement over the standard interpreter on x86-64 Linux, and 12–13% on AArch64 macOS. The official Windows 64-bit binaries now use the tail-calling interpreter too.

The longer game is free-threading. The no-GIL build became officially supported in 3.14, and 3.15 keeps pushing: the macOS installer now ships free-threading support by default, and there's a stable ABI for free-threaded builds. Note the careful wording — supported is not default. Your python3.15 still has the GIL; the free-threaded interpreter is a separate python3.15t build, and the ecosystem is what gates real adoption now. A C extension has to declare itself safe without the GIL, and plenty still don't.

If you ship or depend on C extensions, 3.15's real ask of you is a test run under the t build. Data races only show up under load, and "targets the stable ABI" is a different claim from "correct without the GIL."

There's also a quiet observability upgrade: the Tachyon high-frequency sampling profiler, a dedicated profiling package, and frame pointers enabled by default. Profiling production processes without the observer effect distorting your numbers is getting noticeably easier.

What to do before Friday

The practical checklist is short, and the release team has deliberately made it low-risk:

• Run your suite on 3.15.0rc3. Between rc3 and final, only reviewed bug fixes land — no API changes, no ABI changes. A bug you find this week can still be fixed; a bug you find next week ships to everyone.
• Add 3.15 to CI with prereleases allowed. Binary wheels built against the RCs are guaranteed compatible with the final, and 22% of the top 360 PyPI packages already signal 3.15 support. Don't be the last one in your dependency tree.
• Publish your wheels if you're a maintainer. The ABI freeze means wheels built now work with the final release. The call went out on the release thread; answer it.
• Audit the UTF-8 change. Grep for bare open() calls. Set encoding= explicitly wherever input could be non-UTF-8.
• Test the free-threaded build if you have C extensions. This is the long bet of the 3.15 cycle, and it needs real-world load to prove itself.

Python releases don't break the internet anymore; they sand the edges down a little more each year. 3.15 sands down startup time, configuration plumbing, encoding foot-guns, and the profiler — while the GIL-free future keeps inching from "supported" toward "normal." Test now, upgrade calmly on Friday, and if you maintain a package, ship those wheels this week.

References

• Python 3.15.0 candidate 3 is here! — Python Insider (Oct 2, 2026)
• Python 3.15: following tradition, let's have a surprise rc3! — discuss.python.org
• Major new features of the 3.15 series — python-insider-blog (rc1)
• What Python 3.15 Changes, and What to Test Now — dev.to
• Python 3.15.0rc3 release candidate announced — Linux Compatible
• What's in which Python — Ned Batchelder