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.
As a maintainer of a Python module that uses abi3 now, thank you!
Just one question: any plans to promote APIs like PyUnstable_EnableTryIncRef() and PyUnstable_TryIncRef() into the limited API? So far we have found that these APIs are necessary to implement the weak-valued caches we've always used in the past: https://github.com/protocolbuffers/protobuf/blob/6559a9f9622...
I’m glad to see there’s ongoing work to get protobuf working!
I doubt PyUnstable APIs will get promoted directly to the limited API without at least a release or two in the regular version-specific API first.
That said, if you would be willing to start a thread on discourse describing your need and use-case, that is probably the first step to stabilizing the APIs you want. It may also turn out there’s an alternate way to get protobuf working.
Please do feel free to reach out privately. I’d love to be able
to chat with people working on protobuf and grpcio, they come up reasonably often and it’s hard to get official updates from inside Google.
It should be good to go, but of course I don’t know what your codebase looks like and issues are always possible in any code, “good to go” or no. Please do give it a try and try testing on 3.15 and 3.15t.
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.)
> on Solaris, unlike elsewhere, the packaging system is intended only for system components (and Solaris defines this narrowly), not additional software.
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.
Because my software is better if people who are running a supported-but-not-most-recent Python can use it. I'm willing to inconvenience myself a little for their benefit.
That's only the interpreter released by the Python Software Foundation itself. I can't even remember how long its been since I installed their interpreter but probably at least a decade. In recent years its been Miniforge and before that was Anaconda (before they changed their licensing terms for orgs with 200+ people).
That said, its fair enough to drop support for a particular version whenever you want. I'm merely pointing out that there other providers of Python interpreters that are both widely used and support older versions longer. Other folks mentioned OS distributed doing the same already, but personally I don't use the system interpreter and just leave it alone for whatever the distro needs it for.
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.
You have to draw the line somewhere though. Python 3.10 is over 5 years old. Is upgrading your system once every 5 years too much to ask? Should webapps still support Internet Explorer 6?
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.
It would be great to have less languages and ecosystems rather than more. However, I think that none of these programming systems have hit a peak yet. There's a lot of innovation still to be done, and in that sense, id rather see more divergence and less consolidation.
Rails was a convenient layer that made the time to market shorter. Now Basecamp as pretty much abandoned Rails. Don't think newer projects would be choosing Rails.
Same goes with React Native. Shopify abandoned it.
I see the same fate for Flutter. Many many frameworks and languages might get abandoned gradually. Add Qt to the list as well.
A lot would be erased and newer languages/frameworks won't gain any traction because AI wouldn't be proficient in them hence they are less liely to gain momentum.
Because code still would be read by humans. Check the code for PhotoCraft[0] (clean room reimplementation of Adobe Photoshop) which is being actively written in Rust by AI agents almost 24x7.
Check the overall layered architecture. That's nowhere AI. That's pure human ingenuity coupled with machine's raw horsepower to build on top.
Because it's still cheaper and safer to implement in Rust and allow a compiler to mechanically and deterministically transform it into machine code. The value of abstractions are not going away.
Depends on your build, system configuration, etc. I worked at a place where the data sci’s had a remarkable talent to build docker images based on python images they found in random places and you could wind up with charsets you wouldn’t expect. Managing the problem in code didn’t entirely work because if some third party lib print()ed something that had characters not in the charset it would crash.
> 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.
Because currently abi3t is only relevant for 3.15, its value is future-proofing artefacts for 3.16 and beyond, you need two free threaded wheels at least (3.14t and abi3t).
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.
makes sense (and I somehow missed `mcpyrate` when I scanned the ecosystem for macro packages).
I ended up writing a custom package that expands on the one "macro" (really a small DSL) that does it very quickly, and uses the `.pth` import so it automatically loads, via entrypoint especially, rather than being a constant import in the files that uses the DSL.
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.
As a maintainer of a Python module that uses abi3 now, thank you!
Just one question: any plans to promote APIs like PyUnstable_EnableTryIncRef() and PyUnstable_TryIncRef() into the limited API? So far we have found that these APIs are necessary to implement the weak-valued caches we've always used in the past: https://github.com/protocolbuffers/protobuf/blob/6559a9f9622...
I’m glad to see there’s ongoing work to get protobuf working!
I doubt PyUnstable APIs will get promoted directly to the limited API without at least a release or two in the regular version-specific API first.
That said, if you would be willing to start a thread on discourse describing your need and use-case, that is probably the first step to stabilizing the APIs you want. It may also turn out there’s an alternate way to get protobuf working.
Please do feel free to reach out privately. I’d love to be able to chat with people working on protobuf and grpcio, they come up reasonably often and it’s hard to get official updates from inside Google.
Are you aware of specific issues remaining in pyo3’s abi3t support or is that good to go?
It should be good to go, but of course I don’t know what your codebase looks like and issues are always possible in any code, “good to go” or no. Please do give it a try and try testing on 3.15 and 3.15t.
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...
https://utcc.utoronto.ca/~cks/space/blog/solaris/BadSolarisP...
> on Solaris, unlike elsewhere, the packaging system is intended only for system components (and Solaris defines this narrowly), not additional software.
Which points to this:
https://web.archive.org/web/20110411135805/http://holyhandgr...
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_...
Even 3.12 will be EOL half a year before RHEL 8's.
And "support" doesn't mean you get the same package selection as the original:
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.
> 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.
Then why not just support Python >= 3.14 or whatever and that's it?
Because my software is better if people who are running a supported-but-not-most-recent Python can use it. I'm willing to inconvenience myself a little for their benefit.
That's only the interpreter released by the Python Software Foundation itself. I can't even remember how long its been since I installed their interpreter but probably at least a decade. In recent years its been Miniforge and before that was Anaconda (before they changed their licensing terms for orgs with 200+ people).
That said, its fair enough to drop support for a particular version whenever you want. I'm merely pointing out that there other providers of Python interpreters that are both widely used and support older versions longer. Other folks mentioned OS distributed doing the same already, but personally I don't use the system interpreter and just leave it alone for whatever the distro needs it for.
Anaconda follow the PSF support cycle these days: https://www.anaconda.com/docs/reference/policies-practices/p...
"Anaconda is ending support for Python 3.10 in October 2026."
The most notable holdouts are the various "enterprise" Linux distributions, see other comment: https://news.ycombinator.com/item?id=50021127#50023030
Good to know. Just one more reason to not use the Anaconda interpreters.
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.
You have to draw the line somewhere though. Python 3.10 is over 5 years old. Is upgrading your system once every 5 years too much to ask? Should webapps still support Internet Explorer 6?
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.
He has contributed by highlighting the waste!
Inappropriate answer to someone saying that adding 10 MB worth of GIFs to a source code tarball is inadequate.
This might irk many but going forward, I see only following languages surviving:
1. Typescript + Javascript
2. Rust.
3. Python - because of data science and interactive apps.
Basically, everything that can be rewritten in Rust with or without AI will be rewritten in Rust with or without AI in coming decade.
Famous cases:
1. Some backends at 37 signals from Ruby to Rust.
2. Bun from Zig to Rust.
3. Git in transition.
4. Mold linker from C to Rust.
5. Biome
6. TailwindCSS CLI
And much much more. Even Python interpreter is in process of using Rust as the main language if I am not wrong.
[0]. https://github.com/kevincouton/awesome-rust-migrations#1
C will continue to be running on embedded processors until the end of time.
It would be great to have less languages and ecosystems rather than more. However, I think that none of these programming systems have hit a peak yet. There's a lot of innovation still to be done, and in that sense, id rather see more divergence and less consolidation.
Don't think so.
Rails was a convenient layer that made the time to market shorter. Now Basecamp as pretty much abandoned Rails. Don't think newer projects would be choosing Rails.
Same goes with React Native. Shopify abandoned it.
I see the same fate for Flutter. Many many frameworks and languages might get abandoned gradually. Add Qt to the list as well.
A lot would be erased and newer languages/frameworks won't gain any traction because AI wouldn't be proficient in them hence they are less liely to gain momentum.
That's the future, whether we like it or not.
Those 3 are my favorites languages, so I agree.
I'd add Go to the mix but yes all three are amazing languages. You do not need Java/C#/PHP etc anymore.
Since you've mentioned AI why not go directly to machine code, i.e. assembly or even binary?
Because code still would be read by humans. Check the code for PhotoCraft[0] (clean room reimplementation of Adobe Photoshop) which is being actively written in Rust by AI agents almost 24x7.
Check the overall layered architecture. That's nowhere AI. That's pure human ingenuity coupled with machine's raw horsepower to build on top.
And such people do need to read the code.
[0]. https://github.com/storytold/photocraft
I just wish Rust were slightly more readable...
The async terrain is absolutely bonkers and not just not very readable but also not very understandable either I suppose.
programming languages may just be a really good abstraction level to describe what you want.
Because it's still cheaper and safer to implement in Rust and allow a compiler to mechanically and deterministically transform it into machine code. The value of abstractions are not going away.
That's just ridiculous. Not sure if you're serious, but if so, please make a serious attempt at this argument.
> 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:
PEP 686 for the win!
https://peps.python.org/pep-0686/
I really thought UTF-8 was already the default.
Depends on your build, system configuration, etc. I worked at a place where the data sci’s had a remarkable talent to build docker images based on python images they found in random places and you could wind up with charsets you wouldn’t expect. Managing the problem in code didn’t entirely work because if some third party lib print()ed something that had characters not in the charset it would crash.
> 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.
> 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.
Do you mean way back when abi3 became useable?
Because currently abi3t is only relevant for 3.15, its value is future-proofing artefacts for 3.16 and beyond, you need two free threaded wheels at least (3.14t and abi3t).
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
makes sense (and I somehow missed `mcpyrate` when I scanned the ecosystem for macro packages).
I ended up writing a custom package that expands on the one "macro" (really a small DSL) that does it very quickly, and uses the `.pth` import so it automatically loads, via entrypoint especially, rather than being a constant import in the files that uses the DSL.
`mcpyrate` looks very cool.
Been waiting for lazy imports for a long time now, glad to see them finally.
Whats your application? I'm curious.
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
Related:
How Fast is Python 3.15?
https://news.ycombinator.com/item?id=49984652
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.
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.
<3