I have to wonder why Python as a communities have always have the interested to substantially speed up Python. While the Ruby Camp has always been about if you want more speed, do it in C. ( Best Tools for the Job manta? ) Although I hope Ruby MRI will one day get its own Google V8 / LuaJIT treatment.
Not sure I agree with that - a big part of the excitement about 1.9 was how much faster it was, and stock Python isn't significantly faster than YARV. Didn't Python 3 actually come with a modest reduction in performance when it was released?
PyPy's certainly ahead quite a bit, but it still seems rather ignored by most.
> I hope Ruby MRI will one day get its own Google V8 / LuaJIT treatment.
Rubinius is a JITing LLVM-based Ruby VM with accurate compacting generational GC and no global interpreter lock. And of course there's the similarly capable JRuby, which leverages the JVM JIT quite heavily.
http://morepypy.blogspot.com/2011/10/speeding-up-json-encodi...
I can also tell you that the idea of simply using c for the slow parts is good but it's not too difficult to build a largish project in a dynamic language where that's very difficult. A high speed kernel with slow control plane can still be slow.
Pyston seems like it has some interesting goals and it might achieve them. There are some substantial ones they haven't addressed yet, cough Gil cough. If they are good, it'll just be a faster python, whereas pypy is very good and if the community embraces what they are doing, it's a new kid of thing.
I know of just three Python (re)implementations attempted at least in part for speed, one abandoned (unladen swallow), one just starting(OP one), and one fairly far along but not yet complete (Pypy). All are niche and relatively small efforts compared to rest of Python communities "do it in C".
Projects like pypy lets me code thing in Python I would otherwise have had to do in C. How is that not an awesome thing?
Why a new implementation
There are already a number of Python implementations using JIT techniques, often in sophisticated ways. PyPy has achieved impressive performance with its tracing JIT; Jython and IronPython are both built on top of mature VMs with extensive JIT support. So why do we think it’s worth starting a new implementation?
In short, it’s because we think the most promising techniques are incompatible with existing implementations. For instance, the JavaScript world has switched from tracing JITs to method-at-a-time JITs, due to the compelling performance benefits. Whether or not the same performance advantage holds for Python is an open question, but since the two approaches are fundamentally incompatible, the only way to start answering the question is to build a new method-at-a-time JIT.
Another point of differentiation is the planned use of a conservative garbage collector to support extension modules efficiently. Again, we won’t know until later whether this is a better approach or not, but it’s a decision that’s integral enough to a JIT that it is difficult to test in an existing implementation.
The downside of starting from scratch is, unsurprisingly, that creating a new language implementation is an enormous task. Luckily, tools are starting to come out that can help with this process; in particular, Pyston is built on top of LLVM, which lets us achieve top-tier code generation quality without having to deal with the details ourselves. Nonetheless, a new Python implementation is a huge undertaking, and Pyston will not be ready for use soon.
1. 2.7 is a stable target. There will be no further features added to the 2.x series.
2. 2.7 is a known target. Other experiments like PyPy have already tried many paths to improve 2.7, so what doesn't work is reasonably well known.
3. 2.7 is a widely deployed target. This is less important from an "adoption" point of view, more so that there is a lot of software written that targets 2.x, meaning there's more software to test with.
4. Finally, I suspect much of Dropbox's codebase is 2.7[1], and since this is an effort to improve things for Dropbox, it makes sense to spend the initial efforts there :)
[1] checking the version of Python bundled with the Dropbox client confirms that it, at least, is 2.7
/Applications/Dropbox.app/Contents/MacOS/python --version
Python 2.7.3