Rendered at 16:24:34 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
ngoldbaum 48 minutes ago [-]
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.
yablak 30 minutes ago [-]
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.
simonw 1 hours ago [-]
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!)
em500 24 minutes ago [-]
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.)
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.
ryandrake 1 hours ago [-]
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.
zahlman 50 minutes ago [-]
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.
wtallis 50 minutes ago [-]
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.
zahlman 1 hours ago [-]
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.
HackerThemAll 48 minutes ago [-]
> 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.
kbumsik 59 minutes ago [-]
> PEP 810: Explicit lazy imports for faster startup times
Yes lazy import! Finally!
frodowtf2 5 minutes ago [-]
Is there any reason to not enable it globally?
simonw 1 hours ago [-]
OK this is fun:
uvx --python 3.15 whatsnewt
hncbw02z5a 9 minutes ago [-]
Shipping one abi3 wheel instead of per version builds cut our CI matrix from like 20 jobs to 4, that alone was worth it.
droidjj 1 hours ago [-]
> 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!
fishgoesblub 54 minutes ago [-]
Been waiting for lazy imports for a long time now, glad to see them finally.
Yeah Sentinel and lazy imports just took me to the bottom of the page. I had to find them the old fashioned way
OutOfHere 1 hours ago [-]
Some should now be fixed as the documentation pages get updated to point to 3.15.
lsofzz 1 hours ago [-]
<3
OutOfHere 1 hours ago [-]
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.
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.
Here's the "what's new in Python 3.11" document: https://docs.python.org/3/whatsnew/3.11.html
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!)
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...
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.
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.
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.
Just take your time to contribute that to the project, it's a win-win.
Yes lazy import! Finally!
Nice to see improvements here!
How Fast is Python 3.15?
https://news.ycombinator.com/item?id=49984652