> but they surely didn't think that
They surely did! And it tells me you don't know the history that well.
You can read PEP 3000 where they say almost exactly that, at https://peps.python.org/pep-3000/ :
The recommended development model for a project that needs to
support Python 2.6 and 3.0 simultaneously is as follows:
0. You should have excellent unit tests with close to full coverage.
1. Port your project to Python 2.6.
2. Turn on the Py3k warnings mode.
3. Test and edit until no warnings remain.
4. Use the 2to3 tool to convert this source code to 3.0 syntax.
Do not manually edit the output!
5. Test the converted source code under 3.0.
6. If problems are found, make corrections to the 2.6 version of
the source code and go back to step 3.
When it’s time to release, release separate 2.6 and 3.0 tarballs (or
whatever archive form you use for releases).
They really did not consider having a usable subset that could work on Python 2 and Python 3. The same PEP says:
There is no requirement that Python 2.6 code will run unmodified on
Python 3.0. Not even a subset. (Of course there will be a tiny subset,
but it will be missing major functionality.)
Remember, it wasn't even until Python 3.3 that they restored the u'unicode' syntax "provided solely to reduce the number of purely mechanical changes in migrating to Python 3, making it easier for developers to focus on the more significant semantic changes (such as the stricter default separation of binary and text data)."
https://docs.python.org/3.3/whatsnew/3.3.htmlAnd it wasn't until Python 3.5 that they supported old-style %-formatting, like (b"%d" % n), both because it's useful in wire protocols, and "to help ease migration from, and/or have a single code base with, Python 2" https://peps.python.org/pep-0461/ .
> No GIL ... and so on
The features you listed required years of development, and some, like the JIT support, are still in-progress, while the no-gil proposal seems beyond what the steering committee is willing to accept.
It sounds like you want them to have delivered Python 3.12, with all these features (many of them iterated on over several releases), instead of 3.0, and without any migration path from 2.x Python or Python/C extensions beyond wholesale rewriting.
There is no way they would have manged to timely deliver a stable release following your suggestion. As it was, it took about a decade to deliver a version that had a effective migration pathway. Python 3.5 is the first version I supported, in no small part because it supported bytes % interpolation.
> And not because it couldn't just as well be added piecemeal to some 2.8 and onwards...
Perhaps it could have been done in an abstract and technical sense. But the Python core developers decided they didn't have the resources (money, people, etc) for that path.
I don't see how some of the changes, like exception chaining, could have been implemented without breaking backwards compatibility. Even things as simple as evaluating (a<b) or "Hello".encode("base64") changed at a pretty deep level.
Remember, Python 3 was always meant as "a relatively mild improvement on Python 2, [because] we can gain a lot by not attempting to reimplement the language from scratch." https://peps.python.org/pep-0461/ That was how the effort was justified.
The Perl6/Raku experience was definitely part of the zeitgeist in the discussion against larger changes like you think were needed.
What are your counter-examples that might sooth the concerns should a cusp like this appear in the future? I can't think of any good ones.
> and cost the community 5-6 years for nothing much. Everything big came later in 3.x.
The core developers argued that the technical debt in the code base was high, and while it would take years, those changes would enable the later big improvements you now see.
You seem to look at the big improvements and somehow believe they could have been done 15 years ago, on the old code base, with the available knowledge and resources of the people then.
You believe this because, why?