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...
> 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...
Python 3.9 is still included in Xcode and the Command Line Tools, but not the OS itself. It’s only for running scripts (and for supporting LLDB I think), applications cannot link against it like they could with the old OS-bundled 2.7.
Python 3.9 is getting conspicuously old though, I was a bit surprised Apple didn’t update it in Xcode 27.
> 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.
- 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)* https://docs.redhat.com/en/documentation/red_hat_enterprise_...
As does RHEL9:
* https://docs.redhat.com/en/documentation/red_hat_enterprise_...
And "support" doesn't mean you get the same package selection as the original:
$ yum search 'python3' 2>&1 | grep '^python3-' | wc -l
1551
$ yum search 'python3' 2>&1 | egrep '^python3(8|9|\.)' | wc -l
279https://access.redhat.com/support/policy/updates/rhel-app-st...
The support lifecycles are divergent from the rest of the OS though. Only the base Python version gets full lifecycle support, the newer versions get refreshed occasionally and eventually fall out of support.
The distro may keep applying security patches to old Python versions but there are definitely limits to what's feasible. If you try to build 3.6 or earlier from source today you'll run into issues with getting an old enough OpenSSL version to be compatible (and then you're stuck with the problems of that version). Some of my old-version builds also seem to segfault whenever you try to use `ctypes` (including indirectly, which can happen in very surprising ways) and I haven't fully diagnosed that.
But developers who want to "participate in the ecosystem" are not going to have a fun time regardless, because their dependencies are not going to keep supporting older Python in newer package versions. On the other hand, your old hack scripts will usually still work in even much newer Python versions, unless you tripped on a standard library deprecation landmine or something (which generally only happens with much older stuff than the 5-year support window; see https://peps.python.org/pep-0594/ and check out the "Added in" column in the table).
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.
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
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.
Okay, but that isn't happening here. There isn't even a real way Python developers could do that, even if they wanted to. That isn't how Python package management works.
When the developer wants to start using features from a new Python version, that requires a new release with a higher version number. The old one is still available, and all standard package tooling will restrict itself to the package versions compatible with your Python version. And the ecosystem standard is to restrict yourself, for current releases, to features available in currently supported Python versions (which is why Simon is talking about 3.11 features and not 3.15 ones, or even 3.12 ones).
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.
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 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
Then why not just support Python >= 3.14 or whatever and that's it?
If python interpreters masqueraded as versioned .so libraries, we probably wouldn't even be having this conversation, because having multiple versions of those lying around is ancient precedent.
You can in fact get them in pretty much that form (of course they also include a ton of .py files for the standard library); see https://github.com/astral-sh/python-build-standalone .