What's the best way to achieve the dream of a fast and fleet Python implementation? Depends on whom you're asking.
If you're Dropbox, creators of the burgeoning Pyston project, you start with Python as we know it and add speed to it. If you're PyPy, you start with something fast and make it more like the Python we know over time.
Two competing projects trying to deliver a faster Python isn't a bad thing. In fact, it might end up helping Python users choose exactly the speed they need.
Forging ahead
Pyston is advancing by great strides. Its latest release, version 0.5.1, shows Dropbox cadging more performance out of its JIT-compiling Python implementation. Pyston not only runs faster, according to Dropbox's benchmarks, but also starts faster. Slow startup time is one of the more persistent issues with any JIT compiler for a dynamic language, and Pyston has been trying to overcome that by using inline caching and different kinds of JITting.
PyPy's also been making progress in those areas and in others. Its 5.1 release back in April cut way down on script startup time and diversified support for all the processor and hardware types it supports. This last issue -- broad platform support -- is another PyPy selling point, as it's built using a subset of Python that makes such porting simpler. PyPy also recently introduced a valuable tool for its ecosystem: a Python debugger that can wind backward or forward through a program's state.
Back and forth
One chief difference between Pyston and PyPy: how they approach backward compatibility. Python's big strength is its plethora of existing libraries and apps, so any Python implementation that isn't broadly compatible with them isn't much of a Python implementation. Pyston wants to achieve strong compatibility with third-party libraries that use C extensions, such as SciPy.
PyPy, by contrast, has long had problems with third-party C-powered libraries and has had to add support for them by hand. The widely used math-and-stats library Numpy, for instance, is now supported, but by way of a set of extensions internal to PyPy.
PyPy is trying to work around its limitations with C by encouraging the use of its own C interface, cffi, as opposed to its implementation of Python's C API layer. Cffi is faster and more "Pythonic" than the default C interface in Python -- even non-PyPy users say as much -- but again, the effort involved in porting legacy projects isn't trivial.
Picking your path
Another major contrast between the projects is who's behind them. PyPy is a volunteer project spearheaded by Armin Rigo, with private fundraising efforts. Pyston, by contrast, is a Dropbox project, sponsored by a company that employs Python creator Guido van Rossum, and created mainly to produce something Dropbox will run in production.
Why did Dropbox start anew rather than work with PyPy? Likely because a clean slate not only freed Dropbox of having to assume anyone else's technical debt, but provided a project it could assume complete control over and guide according to its own requirements.
In the short run, it means PyPy now has one less potential source of skilled and valuable input. But in the long run, Python users now have more choice: PyPy with its forward-thinking ecosystem, or Pyston with its emphasis on compatibility.