I wrote explicitly that this is a problem with CPython. I totally agree that this is not the problem of the language itself. Neither are the most of the points from the parent post(tooling, community, performance, error messages). Yet all that still greatly affects your experience with the language. Same applies to the default implementation. I think you would agree if I said that Sun(Oracle) JVM played an important role in Java adoption, wouldn't you? Unfortunately, it's not so easy to just switch to some other implementation of Python: PyPy uses GIL as well, IronPython and Jython don't but they are years behind the current version of the language. GIL is not a problem when you use libraries that handle concurrency natively(e.g. NumPy) but when you try to parallelize some computationally intensive algorithm written in Python you're probably going to hit the wall. I love Python but it's really not a one-size-fits-all tool.

> This isn't an issue with the language, it's an issue with the common implementation of the language.

There is no formal definition of the language. It is defined by the C implementation. So I'm not sure how meaningful that distinction is.

> If neither happens, then I guess it isn't really a problem.

Or people give up on Python and use another language.

Python is not defined by its C implementation. For example, Python-the-language does not require reference counting even though CPython uses that.

The real-world distinction between the Python specification and its implementation started in the late 1990s, with JPython (now Jython).