My headline feature is the new “abi3t” stable ABI for the free-threaded build. While Petr Viktorin did most of the CPython implementation, I’ve been trying to make sure ecosystem support is ready. It’s been a rewarding but quite challenging project to make sure everything is working. There were some late nights leading up to the beta1 release when we found a Windows-specific issue that needed a fix.
I’m particularly proud that the cryptography project is already shipping a single abi3.abi3t wheel for each platform on Python 3.15 or newer. The GIL-enabled build and free-threaded build can both use the same wheel now, because PyObject is opaque.
If you want to learn more about this, I gave a talk at EuroPython this year on Python’s ABI and the road to building and releasing abi3t today. See https://youtu.be/An8lO29SxXE.
Came here to say this. A stable ABI will mean that libraries can make a single free-threaded build that'll last at least a couple of Python versions into the future.
As a maintainer of a whole bunch of open source Python libraries, my favorite thing about a new Python release is that it signifies the end of support for an older one. In this case that's Python 3.10... which means that my libraries that aim to support every current Python version can finally start embracing features from Python 3.11!
Irritatingly, even if you upgrade to the very latest Mac OS X and Xcode, you still get Python 3.9.6.
While you can give people guidance to install a more up-to-date python, everything is much, much harder than the default experience that gives them 3.9.6 (and also once you have them running a custom version with uv or something, may as well just get them to install 3.15!)
This is very deliberate: included scripting runtimes for Python, Ruby are only for compatibility with legacy software, not for any new development. This goes back as far as macOS 10.15 from 2019 [1].
They still haven't gotten around to actually removing them (probably don't want to deal with support/complains), but keeping versions pinned to ancient versions will naturally nudge developers to take care of their own runtime requirements. (They do the same with bash, perl, ruby.)
I know Python versions and dependency management is always awkward for people who don't use it every day, but you should almost never use the bundled version of Python on the system, and instead pin a dedicated version for whatever you're developing. And use a virtual environment. uv solves all of this.
> may as well just get them to install 3.15
Exactly. If the project you're trying to run needs a certain version of Python, it's no concern of the system that you're running on, it's a concern of the environment you're running in.
C build environments and linked libraries don't do this, and it's one of the reasons why I am a fan of isolated Python environments. You can't get into dependency conflict resolution hell if the dependencies are defined by a single system.
Enterprise distros support their python for 10 years anyway. The lack of Python LTS releases results in most versions having longer lifetimes in practice than intended:
So on one hand you're lagging 4 years (and 4 versions) behind, but on the other hand it's just 4 years and 4 versions. I like your approach. Without it there'd be no progress. Google has similar policy in many places.
That's how we can have nice things. People need to just write tests and let renovate automatically update packages, whose safety will be determined by said tests.
As long as 3.11 can be "embraced" without breaking on 3.10. As a user, I might still have 3.10 installed and be happy with it, or be stuck on a system that tops out at 3.10. Unpopular opinion on HN, but I really dislike "I can break users on X because Y is now out" policies :(. I guess I'm always free to just stick to an older version of the application that still supports X.
My policy is that if the Python version isn't supported then I don't have to take steps to support it either.
If you're stuck with 3.10 that's fine, you'll just be stuck with the versions of my packages that I released prior to October 2026.
Thankfully Python packaging has metadata which means "pip install X" will continue to get you the most recent release which is compatible with your Python version.
Realizing this is the thing that gave me the freedom to finally stop worrying about all of those stale installations.
Older versions of Python packages don't stop being available, they just become unsupported. Nothing stops you from using those versions that still work fine on your older Python installation. It's unreasonable to expect free support indefinitely for open-source packages, especially since that would produce an O(n^2) maintenance burden with the emergence of new Python releases.
Even relatively conservative Linux distros, for example, will only leave you with an unsupported-by-the-core-devs system Python for a small fraction of the cycle. For example, Mint 21.x (which distributes Python 3.10) will be EOL at the end of next April.
I suppose the word "support" has many meanings in software. When I say I wish more developers would keep support for old platforms, I don't mean "provide human technical support" to users on old platforms, or even "continue building features" for those old platforms. Just wish they wouldn't deliberately break them.
EOL doesn't mean the software vanishes from the face of the earth, although we seem to be quickly moving to a world where once the OS vendor EOLs a platform, developers take that as a signal to break everyone on that platform.
I know, open source = I'm not entitled to anything, which is why I say "wish" instead of "demand."
> Just wish they wouldn't deliberately break them.
I don't think anyone™ goes out of their way to explicitly break things for old Python versions.
It's usually more like "oh cool I can make this code faster/more readable if I use this feature. I don't have to care about the old version anymore so I will do that."
If you really to super duper need a backport, you're in luck: python is an interpreted language whose source is in plaintext, on your local machine.
If you're writing or packaging software for a specific OS that bundles an old Python, then there's sometimes a reasonable argument for wanting to retain compatibility with that old Python. But now that uv has started bringing some sanity and relative ease to Python package management, it's not much hassle for end users to start running a Python newer than the one shipped by the OS when they want to use a tool or library that requires a newer Python or performs better on a newer Python.
The XZ-compressed source tarball is about half again as large as the one for 3.14. What happened?
Edit: Digging in a bit, a lot of things are slightly bigger overall as you'd expect; but notably the documentation folder has gained two animated GIFs totaling over 10MB (which presumably don't compress too much further even with XZ) demonstrating "tachyon" (which presumably refers to the new sampling profiler, https://docs.python.org/3.15/library/profiling.sampling.html ). These seem to be screen captures from terminal sessions, which work well enough to illustrate what a TUI looks like, but are probably not all that informative about how to use it. I would have much preferred SVG diagrams based around static screenshots.
Hmm I see https://peps.python.org/pep-0829/ is now merged in. I understand why it's necessary, but I was doing some cool things with codecs installing "macros" with `.pth` imports.
> The experimental JIT compiler has been significantly upgraded, with 7-8% geometric mean performance improvement on x86-64 Linux over the standard interpreter, and 11-12% speedup on AArch64 macOS over the tail-calling interpreter.
Whether you use 3.15 or not, if your project already passes a modern type checker, one thing that you can do easily using AI is to significantly tighten (narrow) the type annotations of your functions. Run this two or three times until the annotations are sufficiently but not excessively narrowed. This prevents a whole lot of bugs, and increases clarity of the code for AI.
This matters more for newer versions of Python which actually offer the constructs needed for it. Python 3.15 extends this with sentinel and enhancements to TypedDict.
My headline feature is the new “abi3t” stable ABI for the free-threaded build. While Petr Viktorin did most of the CPython implementation, I’ve been trying to make sure ecosystem support is ready. It’s been a rewarding but quite challenging project to make sure everything is working. There were some late nights leading up to the beta1 release when we found a Windows-specific issue that needed a fix.
I’m particularly proud that the cryptography project is already shipping a single abi3.abi3t wheel for each platform on Python 3.15 or newer. The GIL-enabled build and free-threaded build can both use the same wheel now, because PyObject is opaque.
If you want to learn more about this, I gave a talk at EuroPython this year on Python’s ABI and the road to building and releasing abi3t today. See https://youtu.be/An8lO29SxXE.
Came here to say this. A stable ABI will mean that libraries can make a single free-threaded build that'll last at least a couple of Python versions into the future.
As a maintainer of a whole bunch of open source Python libraries, my favorite thing about a new Python release is that it signifies the end of support for an older one. In this case that's Python 3.10... which means that my libraries that aim to support every current Python version can finally start embracing features from Python 3.11!
Here's the "what's new in Python 3.11" document: https://docs.python.org/3/whatsnew/3.11.html
Irritatingly, even if you upgrade to the very latest Mac OS X and Xcode, you still get Python 3.9.6.
While you can give people guidance to install a more up-to-date python, everything is much, much harder than the default experience that gives them 3.9.6 (and also once you have them running a custom version with uv or something, may as well just get them to install 3.15!)
This is very deliberate: included scripting runtimes for Python, Ruby are only for compatibility with legacy software, not for any new development. This goes back as far as macOS 10.15 from 2019 [1].
They still haven't gotten around to actually removing them (probably don't want to deal with support/complains), but keeping versions pinned to ancient versions will naturally nudge developers to take care of their own runtime requirements. (They do the same with bash, perl, ruby.)
[1] https://developer.apple.com/documentation/macos-release-note...
I know Python versions and dependency management is always awkward for people who don't use it every day, but you should almost never use the bundled version of Python on the system, and instead pin a dedicated version for whatever you're developing. And use a virtual environment. uv solves all of this.
> may as well just get them to install 3.15
Exactly. If the project you're trying to run needs a certain version of Python, it's no concern of the system that you're running on, it's a concern of the environment you're running in.
C build environments and linked libraries don't do this, and it's one of the reasons why I am a fan of isolated Python environments. You can't get into dependency conflict resolution hell if the dependencies are defined by a single system.
macOS bundling Python 3.9 is such a pain. That version hit EOL a full year ago. https://devguide.python.org/versions/
Enterprise distros support their python for 10 years anyway. The lack of Python LTS releases results in most versions having longer lifetimes in practice than intended:
RHEL8 officially supports Py3.11 (since 8.8) and 3.12 (since 8.10):
* https://docs.redhat.com/en/documentation/red_hat_enterprise_...
As does RHEL9:
* https://docs.redhat.com/en/documentation/red_hat_enterprise_...
So on one hand you're lagging 4 years (and 4 versions) behind, but on the other hand it's just 4 years and 4 versions. I like your approach. Without it there'd be no progress. Google has similar policy in many places.
That's how we can have nice things. People need to just write tests and let renovate automatically update packages, whose safety will be determined by said tests.
As long as 3.11 can be "embraced" without breaking on 3.10. As a user, I might still have 3.10 installed and be happy with it, or be stuck on a system that tops out at 3.10. Unpopular opinion on HN, but I really dislike "I can break users on X because Y is now out" policies :(. I guess I'm always free to just stick to an older version of the application that still supports X.
3.10 is EOL and no longer supported: https://devguide.python.org/versions/
My policy is that if the Python version isn't supported then I don't have to take steps to support it either.
If you're stuck with 3.10 that's fine, you'll just be stuck with the versions of my packages that I released prior to October 2026.
Thankfully Python packaging has metadata which means "pip install X" will continue to get you the most recent release which is compatible with your Python version.
Realizing this is the thing that gave me the freedom to finally stop worrying about all of those stale installations.
Older versions of Python packages don't stop being available, they just become unsupported. Nothing stops you from using those versions that still work fine on your older Python installation. It's unreasonable to expect free support indefinitely for open-source packages, especially since that would produce an O(n^2) maintenance burden with the emergence of new Python releases.
Even relatively conservative Linux distros, for example, will only leave you with an unsupported-by-the-core-devs system Python for a small fraction of the cycle. For example, Mint 21.x (which distributes Python 3.10) will be EOL at the end of next April.
I suppose the word "support" has many meanings in software. When I say I wish more developers would keep support for old platforms, I don't mean "provide human technical support" to users on old platforms, or even "continue building features" for those old platforms. Just wish they wouldn't deliberately break them.
EOL doesn't mean the software vanishes from the face of the earth, although we seem to be quickly moving to a world where once the OS vendor EOLs a platform, developers take that as a signal to break everyone on that platform.
I know, open source = I'm not entitled to anything, which is why I say "wish" instead of "demand."
- Sad owner of an iPhone 7
> Just wish they wouldn't deliberately break them.
I don't think anyone™ goes out of their way to explicitly break things for old Python versions.
It's usually more like "oh cool I can make this code faster/more readable if I use this feature. I don't have to care about the old version anymore so I will do that."
If you really to super duper need a backport, you're in luck: python is an interpreted language whose source is in plaintext, on your local machine.
If you're writing or packaging software for a specific OS that bundles an old Python, then there's sometimes a reasonable argument for wanting to retain compatibility with that old Python. But now that uv has started bringing some sanity and relative ease to Python package management, it's not much hassle for end users to start running a Python newer than the one shipped by the OS when they want to use a tool or library that requires a newer Python or performs better on a newer Python.
The XZ-compressed source tarball is about half again as large as the one for 3.14. What happened?
Edit: Digging in a bit, a lot of things are slightly bigger overall as you'd expect; but notably the documentation folder has gained two animated GIFs totaling over 10MB (which presumably don't compress too much further even with XZ) demonstrating "tachyon" (which presumably refers to the new sampling profiler, https://docs.python.org/3.15/library/profiling.sampling.html ). These seem to be screen captures from terminal sessions, which work well enough to illustrate what a TUI looks like, but are probably not all that informative about how to use it. I would have much preferred SVG diagrams based around static screenshots.
> I would have much preferred SVG diagrams based around static screenshots.
Just take your time to contribute that to the project, it's a win-win.
Inappropriate answer to someone saying that adding 10 MB worth of GIFs to a source code tarball is inadequate.
> PEP 798: Unpacking in comprehensions
> PEP 814: Add frozendict built-in type
About damned time. These are little quality of life changes that I've wanted roughly forever. Glad to see them arriving.
> PEP 810: Explicit lazy imports for faster startup times
Yes lazy import! Finally!
Is there any reason to not enable it globally?
The PEP has some notes on this.
https://peps.python.org/pep-0810/#global-lazy-imports-contro...
https://peps.python.org/pep-0810/#making-the-new-behavior-th...
OK this is fun:
Hmm I see https://peps.python.org/pep-0829/ is now merged in. I understand why it's necessary, but I was doing some cool things with codecs installing "macros" with `.pth` imports.
modern macro systems hook into python's import machinery to handle / expand macros, instead of hooking codes or executing code inside .pth files
Take a look at https://github.com/Technologicat/mcpyrate for example
> The experimental JIT compiler has been significantly upgraded, with 7-8% geometric mean performance improvement on x86-64 Linux over the standard interpreter, and 11-12% speedup on AArch64 macOS over the tail-calling interpreter.
Nice to see improvements here!
Shipping one abi3 wheel instead of per version builds cut our CI matrix from like 20 jobs to 4, that alone was worth it.
Been waiting for lazy imports for a long time now, glad to see them finally.
Related:
How Fast is Python 3.15?
https://news.ycombinator.com/item?id=49984652
A large number of the links in the page appear broken for me :/
I clicked through some random ones which all worked, can you describe the ones that didn't work for you and how they failed?
Yeah I had to find a working one low down in the page and edit the PEP number: https://peps.python.org/pep-0790/
Yeah Sentinel and lazy imports just took me to the bottom of the page. I had to find them the old fashioned way
Quite a few nice features, need to play around a bit with them more though. Lazy imports seems nice mainly for my work at the moment.
<3
Whether you use 3.15 or not, if your project already passes a modern type checker, one thing that you can do easily using AI is to significantly tighten (narrow) the type annotations of your functions. Run this two or three times until the annotations are sufficiently but not excessively narrowed. This prevents a whole lot of bugs, and increases clarity of the code for AI.
This matters more for newer versions of Python which actually offer the constructs needed for it. Python 3.15 extends this with sentinel and enhancements to TypedDict.