A bunch of people are mentioning the bugbear of the Python3 migration, but there's an important difference that makes the migration a lot simpler for a backward-incompatible change like this one proposed in PEP760:
You can just write code that is compatible with Python runtimes both before and after the change.
That means that you can use the same test suite, gradually getting the code more and more compatible with the new version, and you can switch your production runtime, without having to worry about a more complicated and involved rollback process.
Notably, in the Python 2->3 migration, it was not really possible (at first[*]) because "" (and b"") literals became -> b""
while u"" literals became -> ""
So, there was no way to write literals that would mean the same thing, and have the same type across the two versions
This is also the reason why libraries like six offered a `six.u` function (https://six.readthedocs.io/#binary-and-text-data) but that required banning use of non-ASCII codepoints in your string literals
[*] This was eventually addressed with PEP 414 (and of course, even with with PEP 414, the migration was not trivial)
> That means that you can use the same test suite, gradually getting the code more and more compatible with the new version, and you can switch your production runtime, without having to worry about a more complicated and involved rollback process.
This is all well and good for your own code, but it’s seldom the case the libraries. A new library release that ‘adds support for Python 3.14’ is very likely to include other changes in the same release that may or may not be trivial, even assuming you were already on the latest version of the library prior to needing to update. A change like this to the Python language might be trivial, but it would have a massive impact on the ecosystem.
> A new library release that ‘adds support for Python 3.14’ is very likely to include other changes in the same release that may or may not be trivial
There's no reason to believe that would be the case. The exceptions are:
- add support for Python 3.0 (that's of course a very different situation as I described before)
- eagerly adopt TONS of Python 3.14-only features (of course that means a different thing than "adds support for")
What a specific release claim to do is irrelevant. The library should run its test suite in CI against multiple Python versions.
in this specific case, updating to 3.14 just mean that the library stopped using bare excepts, which means that all version of Python pre-3.14 would still be able to use the library as usual (and thus, CI of those python versions can be retained).
If you're running a library with a version of Python against which it's not tested, of course you're in a precarious situation (and a bug that silently causes your code to behave differently is going to be a lot more tricky to deal with than a bit of syntax which is not supported anymore).
You can just write code that is compatible with Python runtimes both before and after the change.
That means that you can use the same test suite, gradually getting the code more and more compatible with the new version, and you can switch your production runtime, without having to worry about a more complicated and involved rollback process.
Notably, in the Python 2->3 migration, it was not really possible (at first[*]) because "" (and b"") literals became -> b""
while u"" literals became -> ""
So, there was no way to write literals that would mean the same thing, and have the same type across the two versions
This is also the reason why libraries like six offered a `six.u` function (https://six.readthedocs.io/#binary-and-text-data) but that required banning use of non-ASCII codepoints in your string literals
[*] This was eventually addressed with PEP 414 (and of course, even with with PEP 414, the migration was not trivial)
https://peps.python.org/pep-0414/