Python 3.15

221 points by ngoldbaum 3 hours ago | 41 comments

ngoldbaum 2 hours 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 2 hours 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 2 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!

Here's the "what's new in Python 3.11" document: https://docs.python.org/3/whatsnew/3.11.html

CJefferson 2 hours ago | |

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 2 hours 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.)

[1] https://developer.apple.com/documentation/macos-release-note...

tcdent 1 hour ago | | |

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.

simonw 2 hours ago | | |

macOS bundling Python 3.9 is such a pain. That version hit EOL a full year ago. https://devguide.python.org/versions/

zzzoom 1 hour ago | |

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:

  - 3.14: Ubuntu 26.04
  - 3.12: RHEL 10, Ubuntu 24.04
  - 3.10: Ubuntu 22.04
  - 3.9: RHEL 9
  - 3.8: Ubuntu 20.04
  - 3.6: RHEL 8 (EOL in 2029)

throw0101a 59 minutes ago | | |

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_...

HackerThemAll 2 hours ago | |

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.

esafak 1 hour ago | |

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.

ryandrake 2 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.

nvme0n1p1 1 minute ago | | |

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?

simonw 2 hours ago | | |

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.

zahlman 2 hours 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 2 hours 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 3 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 2 hours 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.

eviks 24 minutes ago | | |

He has contributed by highlighting the waste!

bsoqk 1 hour ago | | |

Inappropriate answer to someone saying that adding 10 MB worth of GIFs to a source code tarball is inadequate.

kbumsik 2 hours ago |

> PEP 810: Explicit lazy imports for faster startup times

Yes lazy import! Finally!

frodowtf2 1 hour ago | |

Is there any reason to not enable it globally?

xtreak29 1 hour ago | | |

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...

simonw 2 hours ago |

OK this is fun:

  uvx --python 3.15 whatsnewt

6gvONxR4sf7o 1 hour ago |

> 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.

droidjj 2 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!

hncbw02z5a 1 hour 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.

rirze 53 minutes ago |

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.

alextremblay 50 minutes ago | |

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

rirze 11 minutes ago | | |

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.

fishgoesblub 2 hours ago |

Been waiting for lazy imports for a long time now, glad to see them finally.

aitchnyu 1 minute ago | |

Whats your application? I'm curious.

alienbaby 3 hours ago |

A large number of the links in the page appear broken for me :/

emmatyping 2 hours ago | |

I clicked through some random ones which all worked, can you describe the ones that didn't work for you and how they failed?

sfink 2 hours ago | |

Yeah I had to find a working one low down in the page and edit the PEP number: https://peps.python.org/pep-0790/

Neywiny 2 hours ago | |

Yeah Sentinel and lazy imports just took me to the bottom of the page. I had to find them the old fashioned way

zshn 2 hours ago |

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.

ChrisArchitect 2 hours ago |

How Fast is Python 3.15?

https://news.ycombinator.com/item?id=49984652

OutOfHere 2 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.

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.

lsofzz 2 hours ago |