> Does anyone know why it still hasn't managed to get enough traction to become the official path for the language
I'd wager BDFL prefers the CPython implementation because it's probably simpler. Also, it supports tons of targets and is super simple to build.
It's healthy for a language to have more than one implementation. A big win would be a linux distro selecting pypy for use as the default Python. But IMO many python scripts that folks use just don't run long enough to see a benefit from PyPy.
> "I'd wager BDFL prefers the CPython implementation because it's probably simpler. Also, it supports tons of targets and is super simple to build."
You're doing good wagering, Guido mentioned just this at several keynotes (source: skim through his PyCon/EuroPython keynotes, there's a good chance he addresses the point or answers a question about it). I'd paraphrase him with: although now a big project with optimizations here and there obscuring the purpose of many parts, CPython remains a boring well-understood "no rocket science" C project. As an example of this, I remember him mentioning how the opcode dispatcher remains a giant `switch` statement rather than something more intricate.
That doesn't mean he dislikes or wants to hinder PyPy (or IronPython or Jython or Pyston or ...), just that he's fine with CPython reach and trade-offs as the "default python", and if you prefer another Python with different performance/compatibility/featureset/xyz characteristics, you're welcome to grab it :)
But it sounds like he implicitly hinders CPython! It sounds like “we won't merge code I don't understand” and no brave intelligent soul will risk improving the interpreter.
Isn't that the explicit job of a BDFL though? To enforce standards? His happens to be simplicity at all costs, and while some might disagree, I think it's generally a good pursuit; as others state, alternative implementations are available if you really need some JITing black magic or Java integration or green threads or...
What's wrong with "we won't merge code we don't understand"? I think a lot of people should hold code to that standard. I think almost everyone does hold code to that standard.
It's a problem when leadership is not ~~merit~~ engagement based (BFDL) and when said leadership is lacking the vision and gut to push Python across new boundaries. I would like to see something more “aggressive” here.
The leadership of Python, in the form of Guido, is certainly merit- and engagement-based. Nothing needs to be 'more aggressive' in Python development. It's perfectly fine for the standard, canonical version of Python to be the version that:
* Is most up-to-date and has all the latest features
* Everyone is most familiar with
* Already is packaged in all operating systems
* Is the most stable
* Is compatible with all C extensions
> I'd wager BDFL prefers the CPython implementation because it's probably simpler. Also, it supports tons of targets and is super simple to build.
At a EuroPython Keynote, the BDFL mentioned that he hasn't had a closer look at PyPy (he mentioned downloading it and playing with it for a few minutes). I.e. there is a certain disinterest. Also, remember that the "Zen of Python" (https://www.python.org/dev/peps/pep-0020/#id3) was written about the design principles of the Python interpreter, and PyPy is not exactly the Zen of python.
Personally, I'd love to see Python 4 to be based entirely on PyPy.
I'd wager BDFL prefers the CPython implementation because it's probably simpler. Also, it supports tons of targets and is super simple to build.
It's healthy for a language to have more than one implementation. A big win would be a linux distro selecting pypy for use as the default Python. But IMO many python scripts that folks use just don't run long enough to see a benefit from PyPy.