Anyway, the core problem is a top-down effort to try to make a programming language of Python 2.x’s level of usage stop to the extent it’s stoppable under its license, because its creators wanted to do something else, as opposed to facilitating its user community to pool resources to continue its development. Does the PSF have a legal obligation to do such facilitation? No. Is the lack of such facilitation bad for parties who bought into Python when it was Python 2? Yes.
They absolutely are. In fact, python 3.9 is in the works right now, which has many new evolutions beyond 2.7.
You're arguing that the psf should treat python2 and 3 as different languages. In their (any my) opinion, this is harmful. It bifurcates python into two incompatible languages. That's bad long term (Perl).
In other words, what's best for python the language, and what's best for python2 the language are not the same. And for the psf, python is more important.
I meant compatible (in the sense that old programs keep running and you can add new stuff to old programs using the new features) evolutions.
> You're arguing that the psf should treat python2 and 3 as different languages.
For practical purposes, they are different languages and the PSF has been treating them as distinct things.
> In their (any my) opinion, this is harmful. It bifurcates python into two incompatible languages. That's bad long term (Perl).
It indeed is bad. I hope that every other programming language community and designer takes a close look at what happened and makes sure never to do a Python 3 analog of their language.
> In other words, what's best for python the language, and what's best for python2 the language are not the same. And for the psf, python is more important.
That's the core problem from the perspective of Python 2 users. The organization that was the steward of the language that they invested in (in the form of writing code in the language) decided not only that a different programming language is more important for the org but that the old language needed to be shut down in order to benefit their new thing.
It's OK for people to get bored with a project and move onto something else, but with the level of usage that Python 2 had and has, it's very problematic for the language steward organization to turn around and seek to shut the language down instead of continuing to evolve it in a way that's respectful of the language users' investment in the language.
How does reusing the name facilitate the development? Every time there is a fork of an open-source project the name changes, precisely to avoid confusions. Reusing the Python name in a fork that is not just a redistribution, but a new version with new features and syntax, is just confusing, unusual and does not help anyone.
There's no `--std=python2` flag you can pass to the interpreter, unfortunately.
Indeed, C++ has rarely made any breaking changes. A decade or so ago, GCC did cause some major ecosystem breakage, by cracking down on C++ constructs which had never been valid according to the spec but which GCC had previously allowed. When that happened, there was a flag to (at least partially) revert to the old behavior: -fpermissive.
