Python 2 code was absolutely not "thrown away just because". Nobody made your interpreter stop working; it was never on a cloud service or anything like that. It just stopped receiving bugfixes from core team (it's open source so everyone was and is free to take over maintenance) and third-party tool and infrastructure support (notably, PyPI) doesn't take it into consideration any more.
Further, the changes were made for very good reasons, such as allowing beginners to accept user input on day 1 without opening ACE exploits in their programs, and having plain double-quoted string literals actually produce a string rather than an immutable byte buffer that vaguely assumes a generic code-page encoding, except for the contexts where it will complain if it's not plain ASCII (admittedly, this is still an improvement over trying to handle text in C with only the standard library), and making sure that decoding operations don't produce encoding errors and vice-versa, and making `isinstance(1<<64, int)` give the expected `True` result, and making `except` syntax make sense, and making sure there aren't two fundamentally different kinds of user-defined class.
And by making these changes, we actually got Python 3 in about 2.5 years (4.5 if you allow for the first couple of releases having some issues figuring out the string literal transition and other such details — I agree they were premature) and were able to offer another 11 (9) for everyone to migrate. Whereas with Raku the entire 13.5 (more like 15.5) year period was spent on design and implementation, and now there hasn't been a new stable release for almost 5 years.
> it's open source so everyone was and is free to take over maintenance
Open source implementations are fine, though the "if you don't like it fork/make your own" argument is, typically a way of sidestepping criticism rather than a practical solution.
But one of Python's greatest weaknesses is that there is no formal language specification. All you have are implementations and their documentation.
From my perspective (suffering through the python 3 transition and living with ongoing changes in 3.x), compatibility was - and is - poorly handled. Many things can and should be done to ease the maintenance burden - things like intelligent defaults, compatibility features and libraries, and not doing stupid things like ripping out the print statement (which could have coexisted with a print() function) with no recourse.
Unfortunately, python's developers seem to have demonstrated tremendous contempt for the users of the language, and for existing code bases.
Other languages (though not all.... <cough, swift>) have actual language specifications and standards (that even keep working as runtime systems evolve), and are not so keen on throwing users and their code off a cliff.
Platforms should absorb pain so that their users don't have to, and avoid introducing breaking changes that multiply pain across an entire user base.
Apple (also known for arrogance combined with contempt for their developers) also gets this wrong, and routinely breaks iOS and swift apps every year.
> things like intelligent defaults
Can you give a concrete example of a problem you encountered while porting 2->3 code caused by a poorly chosen default in 3?
> compatibility features and libraries
You mean like `lib2to3`? Or all the backports 2.7 got, e.g. what's listed at https://wiki.python.org/moin/StandardLibraryBackports ? Or the `__future__` system? Or third-party support like `six` (still immensely popular, though presumably only in CI)?
> the print statement (which could have coexisted with a print() function)
No, it absolutely could not have. Not with the same name, and making the name refer to the function was the point. The print statement syntax was inelegant, quirky and confusing. For example, parentheses can affect the meaning in unusual ways:
Besides which, outputting text has no more logical reason to use a dedicated statement form than inputting text.> python's developers seem to have demonstrated tremendous contempt for the users
I don't understand how you have come to infer such an attitude. Any suspicion that they are introducing breaking changes on a whim will be immediately quashed by reading the discussion behind any of those breaking changes. (Not to mention what happens with the rejected proposals.)
> and avoid introducing breaking changes that multiply pain across an entire user base.
What breaking change was introduced in Python 3.x during your history of using it that caused a nontrivial problem for you? How many years do you believe you were given to account for it?