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