I still don't see that you are actually challenging the original claims, which were simply that splitting the language in two was a very bad idea, and that the

I still don't see that you are actually challenging the original claims, which were simply that splitting the language in two was a very bad idea, and that the split damaged the Python ecosystem. I stand by my claim that any reasonable general-purpose programming language should be able to run simple CPU-bound threaded tasks properly. I didn't claim arbitrary parallel programming should be easy; just that the GIL causes multi-threaded programs written in standard style in Python to not work properly in CPU-bound contexts, because the GIL prevents these programs from using all the cores available, and, furthermore, because even in single-core contexts it is prone to performance failure modes such as convoying and starvation that induce worse performance when there are more cores available. (cf. very extensive discussions in bugs.python.org on GIL problems, along with David Beazley's, Antoine Pitrou's, and others' attempts to address them). It is a standard, uncontroversial expectation of general purpose languages that offer threading that the threads run in parallel, using the available cores. I don't believe this needs substantiation any more than the claim that general purpose programming languages should run serial programs deterministically. I believe the better course for Python post 2.X would have been to fix the core problems with the language's reference implementation, while maintaining backward compatibility with the very large existing code base, rather than adding features of dubious value, doing nothing to address the GIL problem, and breaking compatibility with the vast majority of 2.X code. While this is certainly my opinion, and yours obviously differs, you can't badger away the limitations of the GIL, and you can't just browbeat people into accepting the 3.X series as a good thing. Look, I don't hate the language -- I use it every day and like it a lot. But don't pretend that there aren't real problems with Python when there clearly are -- the discussions on bugs.python.org are mainly driven by strong proponents of the language and are hardly politicized -- and don't pretend that Python 3 wasn't problematic; it's created years -- yes, years -- of problems and confusion with 2 vs 3 incompatibility, has expanded the footprint of the language and changed its semantics in substantive ways (cf. the many, many accepted PEPs post 2.X) that make implementing the language harder. Every language bump (whether 2.5 to 2.6 or 2.7 to 3.0) has meant additional work for the developers of alternative implementations; this is obvious on the face of it; you need only read these projects' blogs and look at the elapsed calendar time.