There is also pyston, which is a 'competing' LLVM backed JIT that Dropbox is working on. Guido also happens to be working at Dropbox, but I don't know if he's directly involved with pyston or not.

AFAIK, many people thought Python 3 would be based on PyPy too

Don't think so. Some people hoped that Python 3 might be based on Unladen Swallow, which was a different Python JIT that Guido was working on while at Google, but that project never really got off the ground and Google seemed to lose interest in it.

>Guido also happens to be working at Dropbox, but I don't know if he's directly involved with pyston or not.

With the proviso that a lot can change in two years, here's a relevant comment from the Dropbox Pyston announcement [1]:

"Guido's advice has been extremely helpful, but so far we haven't been able to get any code from him"

[1]: https://blogs.dropbox.com/tech/2014/04/introducing-pyston-an...

Why do people always give a single person all the credit? I don't think Guido was ever really involved in Unladen Swallow or that he has any particular interest in JIT compilers.

I don't think I gave him all the credit. We where talking about Guido and I mentioned a relevant project I thought (perhaps erroneously) that used to work on.

pypy still has the GIL.

Hopefully not for long: http://doc.pypy.org/en/latest/stm.html

STM isn't magic. Transactions can and will silently fail and you lose your parallelism. You need additional tools to identify and debug failed transactions and you'll need to learn how to structure your code to avoid failed transactions.

This might turn out to be quite difficult for non-trivial Python applications.

STM is exciting but I think it's important to keep in mind that it's an experiment that while promising might still fail in practice.

> "STM isn't magic."

What difference does that make. STM will still enable the removal of the GIL. If an applications is coded that doesn't work with PyPy, that's a separate matter.

But first it has to actually work. So far, based on that page, it has suffered the same fate as all the other attempts to remove the GIL; mostly functional, but slower. And the numbers cited on that page put it on the rather slow side for single-threaded code for a GIL removal, too, which is what has always prevented previous efforts from getting merged in.

I remain skeptical that STM is a good fit for this problem, as I was when I first heard about this, and after their work, alas, I have to say I see little evidence to make me change my mind on that. STM is something that probably needs to be baked in from day one, possibly all the way into the language itself, not put on the side of a complicated secondary implementation of Python.

> "So far, based on that page..."

From the page... "THIS PAGE IS OLD, THE REST IS ABOUT STMGC-C7 WHEREAS THE CURRENT DEVELOPMENT WORK IS DONE ON STMGC-C8"

This page is probably a better starting point for the current PyPy STM work:

http://pypy.org/tmdonate2.html

I didn't see anything newer there to suggest they've made a lot of progress since that page, though.

Part of the problem is that they're trying to wedge into a really tight window; for all its flaws, the GIL is not all that expensive (relative to how slow Python in general is, anyhow), and trying to do it on PyPy makes their window even smaller. It's a really hard thing to hit, and I'll believe it when I see it. I'm not saying it's impossible. Just, I'll believe it when I see it, and I don't recommend a high degree of confidence that it will occur. Nor do I recommend that you use it as part of your advocacy... it's nowhere near solid enough to be making promises about it to people outside the community.

> "I'll believe it when I see it".

You may be interested in this...

"Leysin Winter Sprint (20-27th February 2016)"

"STM (Software Transaction Memory), notably: try to come up with benchmarks, and measure them carefully in order to test and improve the conflict reporting tools, and more generally to figure out how practical it is in large projects to avoid conflicts"

http://morepypy.blogspot.co.uk/2016/01/leysin-winter-sprint-...

> "Nor do I recommend that you use it as part of your advocacy."

I'm an advocate for F#, but I'll encourage the progress of any open source language, strong competition is good for the field as a whole. The question isn't 'Why can't Python be fast?' but rather 'How fast can Python be?', the difference is a difference in attitude.