The question has been asked numerous times on various PyCons. And all the time Guido says that python is "fast enough" and doesn't need all the complications that JIT will bring into the codebase. In the same vain he speaks of GIL as something that is good enough and need not be removed.
For me both of the points sound like a denial and I'm extremely happy that there is a PyPy team who cares about performance and concurrency. The core python team is working on minor tweaks and small-ish features in 3.x which can't hold a candle to solid 2-3x performance increase, built-in support for stackless/greenlets, extremely fast built-in subset of numpy and prospects of running your code truly concurrently with stm.
IIRC, on of his reasons was that CPython works on a large set of architectures and OSes and it's impossible to write a JIT that works on all of them. JITs usually support only the most popular architectures(x86 and x86_64) and CPython wants to remain as architecture-agnostic as possible.
That's a bullshit argument and I don't think it was raised. You can always run JIT on a subset of architectures (ARM, x86, x86_64, PPC and MIPS really cover a lot) and run interpreter on others.
The argument was always "easier to maintain", but that said, unladen swallow was agreed to be merged into cpython, had it met it's goals.
> In the same vain he speaks of GIL as something that is good enough and need not be removed.
If you want to remove the GIL and come up with a way to make the thousands of 3rd-party modules still work, please do it. Beazley has investigated it, but if you think you can do better, please do it.
Most people seem to flock to the reference implementation of a language rather than alternatives. Which is why most people use CRuby even though JRuby is faster.
Guido should just take it like a man and accept a pull request to merge PyPy's JIT interpreter into CPython.
The 3.x branch still has a GIL, so those modules can still be compiled to work with python 3. If you think it is a lame excuse, you obviously haven't looked into the details and you don't understand the problem.
For me both of the points sound like a denial and I'm extremely happy that there is a PyPy team who cares about performance and concurrency. The core python team is working on minor tweaks and small-ish features in 3.x which can't hold a candle to solid 2-3x performance increase, built-in support for stackless/greenlets, extremely fast built-in subset of numpy and prospects of running your code truly concurrently with stm.