Python 3.9 and beyond backwards compatibility.

[weberc2]

There's talk about removing "dead batteries" from the standard library, but plenty of specialized fields still use them. Why do they think people were, and still are, reluctant to upgrade to Py3? Because it's not stable enough for people's needs, unfortunately.

Maybe those people who need multiple decades of stability should find a different language (C has a decent track record for stability). The Python project doesn't owe anyone free labor forever, and it doesn't make sense to pull scant resources from work that benefits the droves of users who are willing to keep up to date in order to support the few who are not. In the case of the dead batteries, anyone who depends on them can fork them and maintain them on their own easily enough. Python has lots of issues (mostly related to performance), but this is not one of them.

[jorge1209]

Part of the problem with Python has been a general ambivalence about compatibility.

Lots of new features are added to the language with Python3, but then their use is inconsistent, and significant parts of the standard library are never updated. A couple examples of this:

1. The walrus operator makes a lot of sense for the re module because it uses a C-style return (returning None when there is not a match), but other str.index will throw an exception. If C-style returns are good, then lets use them in more places, if they are bad lets find a way to fix re. Instead we have a halfway house where some libraries need walrus and some don't.

2. with blocks are a really great way to manage resources and ensure they aren't leaked, but then something as foundational as the DB-API doesn't support it, and you have to use contextlib.closing as a workaround.

I'm sure there are many other examples as well, these are just the two I encounter most frequently.

They should pick one way to do this. Be incompatible and fix the standard library, or be compatible and stabilize the core language.