Python 3.15 Release Highlights

[u/ossm-me]

Python 3.15 has reached Release Candidate 1, and the final release is expected on October 1, 2026.

I went through the changes and tried to summarize the ones that seem most relevant for everyday Python development without going through all the PEP numbers.

- Faster startup with lazy imports

Python 3.15 introduces lazy imports, which means some modules can be loaded only when they are actually needed instead of being loaded immediately.

This could help applications and CLI tools that spend a noticeable amount of time importing modules before doing any actual work.

- UTF-8 becomes the default

UTF-8 is becoming the default encoding, which should reduce encoding-related problems, especially when code is running on different operating systems.

This should make situations where something works on one computer but fails because of a different system encoding less common.

- Built-in immutable dictionaries

Python 3.15 adds a built-in "frozendict"-style immutable mapping.

Similar to how a tuple provides an immutable alternative to a list, this gives Python developers a standard way to work with dictionaries that cannot be modified.

- JIT improvements

The JIT compiler continues to improve in Python 3.15.

Early benchmarks show performance improvements in some workloads, including roughly 8–9% on Linux and larger improvements in some Apple Silicon tests.

These numbers will obviously depend on the workload, so I would wait for more benchmarks before making broader conclusions.

- New profiler: Tachyon

Python 3.15 also introduces Tachyon, a new sampling profiler designed for very low overhead.

It can sample running programs at very high frequencies and can also be attached to an already-running process.

This could be useful for finding performance problems without having to restart an application with a profiler attached from the beginning.

- Some terminal improvements

The interactive Python experience is getting a few smaller improvements, including colored error messages and prompts.

The "sqlite3" command-line interface also gets SQL keyword completion.

- Free-threaded Python is still opt-in

Python 3.15 does not make the no-GIL/free-threaded build the default.

It is still something you have to explicitly use.

However, free-threaded Python is becoming more mature, including improvements to ABI support that should make it easier for C extension developers to support it.

Overall, Python 3.15 doesn't look like a release that completely changes how Python is written. Most of the changes are focused on performance, tooling, and improving some long-standing parts of the language.

Since this is already RC1, the major feature set should be mostly locked and the remaining work should mainly be bug fixes and final polishing.

Has anyone here been testing the Python 3.15 beta or RC?

I'm especially interested in whether lazy imports have caused compatibility problems with existing projects.

[u/Significant_Map_19]

lazy imports are going to break so many frameworks that do weird metaprogramming stuff at startup, I can already feel the bug reports piling up

the frozendict thing is nice though, been using dicts as immutable keys with wrappers for years

[u/jdehesa → u/Significant_Map_19]

You have to explicitly opt in for lazy imports, it's not going to effect existing code.

[u/billsil → u/jdehesa]

It’s not going to be in existing code for 5+ years. It’s going to break compatibility with old versions unless they retroactively add a future import.

[u/chase45424 → u/billsil]

It's isn't a future import but there is a backwards compatible way to specify an import as lazy (similar to dunder all) that will be a no-op on older python versions.

[u/HommeMusical → u/billsil]

Existing code will not be broken.

Lazy imports will never be the default.

There will be an environment variable you can set to make imports lazy everywhere, but that's strictly optional.

[u/Wonderful-Habit-139 → u/HommeMusical]

They will be default once Python versions that don't support it reach EOL.

[u/HommeMusical → u/Wonderful-Habit-139]

Your statement is false.

The PEP says in multiple cases that there is no plan to do this, e.g. https://peps.python.org/pep-0810/#module-level-lazy-import-mode and https://peps.python.org/pep-0810/#making-the-new-behavior-the-default

[u/Wonderful-Habit-139 → u/HommeMusical]

Ahh you mean like actually the default.

I meant more like, using lazy imports instead of workarounds afterwards. I focused more on the "existing code will not be broken" part it seems.

Guess we agree then.

[u/billsil → u/HommeMusical]

An environment variable isn’t going to make python 3.14 work with lazy imports.

[u/HommeMusical → u/billsil]

I'm not seeing your point.

It has always been the case that new features in the language cannot work with older versions of the language, so you pick the minimum version you support, and use that feature set.

[u/wRAR_ → u/billsil]

Which is also not a breakage.

[u/billsil → u/wRAR_]

It is if you want to support multiple versions of python.

Backwards compatibility should not be the only goal. Forwards compatibility matters as well.

[u/wRAR_ → u/billsil]

You seem confused.

[u/wRAR_ → u/billsil]

I expect __lazy_modules__ to be used in some amount, but also not all "existing code" is OSS libraries and apps that are expected to run on all supported Python versions, you can freely use it in your local code.

[u/billsil → u/wRAR_]

I run an open source project, so I’m acutely aware of dependencies. On every supported python version, you should support every version of a dependency (assuming your dependencies don’t conflict). I code work libraries in the same way with a reduced set of python versions.

It’s not up to me to specify a python version. It’s a per project/team decision.

[u/wRAR_ → u/billsil]

Well if you run an open source project then yes, you should fall back to __lazy_modules__.