It's about time. Python shouldn't be in the OS at all, and definitely not for core system utilities that need a working (and small) interpreter with few dependencies that can be easily upgraded.
The way the Python community handled the deprecation and EOL of 2x was a total disaster. Python isn't (or wasn't) only a toy language. It was being used for real, production code, in many cases for a decade or more. That's not to say that upgrades should be impossible, but (except for security patches), a language is such a core piece of infrastructure that you can't change it in an incompatible way without breaking working systems everywhere, and for no reason.
It was truly bizarre that a new, backwards-incompatible version was created really just to fix a missing unicode datatype and add async. Both of these could have been added to the core language or as a library. In fact, I'd argue that even if adding that to the core language was quite difficult (and I don't believe it would have been), it doesn't matter, because you don't break production code.
Python was a nice language to read and write, but considerations of long-term community support, your ability to support deployed apps, a commitment to backwards-compatibility, packaging, and a focused and workable deployment story, are all eminently practical concerns that (in many cases) completely override any otherwise nice features of the language.
The strange behavior of the python community seemed to indicate that they're not at all interested in the billions or trillions of lines of production Python 2x code out there, and that if you are going to eventually upgrade the underlying OS, you now have to completely rewrite all of those lines, even if the original developer isn't even there anymore and the app was working just fine. It was the Y2K problem all over again, but this wasn't due to short-sightedness or byte thriftiness while coding from 20 years prior, but simply because the developer bet on the wrong horse! But what a pretty horse..
Some people still say, "oh, but there were ten years before it was EOL'ed", but the reality is that Python 3000 was never spoken of as being the next (completely incompatible) version of Python, but instead was an experiment, until one day it wasn't anymore.
And then it became Python 3. And, far, far worse: the PSF took an extremely aggressive stance about enforcing the trademark and not allowing a fork (even maintained by others) of Python 2x. This is extremely antithetical to open source principles.
Python's pain was largely self-inflicted, and Python proved that it really only wanted to be a hobbyist language. Some languages might have aspirations of being a 100 year language, but apparently not Python.
Many people (including me) have now spent millions of dollars ripping and replacing Python code. Sure, we should have seen the writing on the wall back in the Python 3000 days, but, surely, we might have thought, didn't the PSF just see what happened with the Perl 5/6 debacle (a similar backwards-incompatible split that split the community and basically killed Perl) a few years prior and weren't going to make the same mistake?
> It was truly bizarre that a new, backwards-incompatible version was created really just to fix a missing unicode datatype and add async.
That's a very reductive way of looking at what was in reality a far more complicated situation, that required a tremendous amount of engineering to even arrive at the compromises they came to. It's not very charitable to all the folks who worked very hard to make that transition even happen.
You think they would have actually gone through all this pain and trouble to add a unicode type and some async? You'd think if it were that easy, MS, Google, Dropbox, and friends would have just banded together, slapped on some unicode classes, and called py2.8 a day.
The problems necessitating python3 run far deeper than that.
The way the Python community handled the deprecation and EOL of 2x was a total disaster. Python isn't (or wasn't) only a toy language. It was being used for real, production code, in many cases for a decade or more. That's not to say that upgrades should be impossible, but (except for security patches), a language is such a core piece of infrastructure that you can't change it in an incompatible way without breaking working systems everywhere, and for no reason.
It was truly bizarre that a new, backwards-incompatible version was created really just to fix a missing unicode datatype and add async. Both of these could have been added to the core language or as a library. In fact, I'd argue that even if adding that to the core language was quite difficult (and I don't believe it would have been), it doesn't matter, because you don't break production code.
Python was a nice language to read and write, but considerations of long-term community support, your ability to support deployed apps, a commitment to backwards-compatibility, packaging, and a focused and workable deployment story, are all eminently practical concerns that (in many cases) completely override any otherwise nice features of the language.
The strange behavior of the python community seemed to indicate that they're not at all interested in the billions or trillions of lines of production Python 2x code out there, and that if you are going to eventually upgrade the underlying OS, you now have to completely rewrite all of those lines, even if the original developer isn't even there anymore and the app was working just fine. It was the Y2K problem all over again, but this wasn't due to short-sightedness or byte thriftiness while coding from 20 years prior, but simply because the developer bet on the wrong horse! But what a pretty horse..
Some people still say, "oh, but there were ten years before it was EOL'ed", but the reality is that Python 3000 was never spoken of as being the next (completely incompatible) version of Python, but instead was an experiment, until one day it wasn't anymore.
And then it became Python 3. And, far, far worse: the PSF took an extremely aggressive stance about enforcing the trademark and not allowing a fork (even maintained by others) of Python 2x. This is extremely antithetical to open source principles.
Python's pain was largely self-inflicted, and Python proved that it really only wanted to be a hobbyist language. Some languages might have aspirations of being a 100 year language, but apparently not Python.
Many people (including me) have now spent millions of dollars ripping and replacing Python code. Sure, we should have seen the writing on the wall back in the Python 3000 days, but, surely, we might have thought, didn't the PSF just see what happened with the Perl 5/6 debacle (a similar backwards-incompatible split that split the community and basically killed Perl) a few years prior and weren't going to make the same mistake?