[leephillips]

I wouldn't expect mainline Python to get significantly faster. You can get huge improvement in speed by using various libraries, alternative interpreters, and other strategies - but you'll always be going beyond "pure", standard Python.

Julia is designed with numerical performance in mind, and gets impressive results out of the box. But, because of the aforementioned, that by itself would probably not be a compelling reason to learn a new language. Such reasons would be Julia's design, which may make it preferable to you once you've learned more about it. Read up on multiple dispatch, built-in networked computing, and array syntax. I find the design around multiple dispatch to be much more sensible than Python's object-oriented approach.

[coldtea]

>I wouldn't expect mainline Python to get significantly faster.

Why not? JS did. And before you mention that it's the de facto language of the web, so of course had tons of commercial backing, well, PHP did too (with PHP7, but also with recent 3 releases really working on speed and less memory use).

We have this Dropbox initiative too, and renewed talk about Python optimization.

For Python it's an obvious shortcoming, with some low-hanging fruits available.

[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.

[jurip]

It's been an obvious shortcoming for over 20 years, though. Maybe it'll get better some day, but at this point it's probably best not to count on it.