[StefanKarpinski]

The tricky thing about Python is that it's a classic two-language system how performance critical extensions to the language are all implemented. That was never the case with JavaScript since there was no way to extend it in C. So the V8 team was free to do anything they wanted to make JS fast so long as it still behaved like JS. Alex Rubinsteyn explained the problem far better than I will manage to in this blog post:

http://www.phi-node.com/2013/06/how-fast-can-we-make-interpr...

The conclusion is that if you do all the things you can to make Python faster without breaking compatibility with CPython (thereby losing all of SciPy):

> "In the best cases, such as when lots of integers are being manipulated in a loop, [you] might get up to 3X faster than the regular Python interpreter. More often, the gains hover around a meager 20%."

[coldtea]

One way might be to make the regular C extension API have a performance drop (e.g use it through some translation layer facade) and introduce a new C extension API alongside it that plays well with the necessary changes in the language.

Do you think that will be feasible for Python?

[StefanKarpinski]

Honestly, I just don't think this is going to happen in Python, but I could very well be wrong. The biggest impediment had been Guido van Rossum's (IMO understandable) reluctance to accept performance improvements that increase the complexity of the standard implementation. The fact that he works at Dropbox, which is also the home of the Pyston project gives some hope of him being more supportive of this kind thing in the future, but that's pretty thin.