On 4/2/2011 3:30 AM, Stefan Behnel wrote:
Cython actually supports most Python language features now (including generators in the development branch), both from Python 2 and Python 3. Chances are that the next release will actually compile most of your Python code unchanged, or only with minor adaptations.
Cython requires the user to insert type declarations, though, to get a speed improvement. Shed Skin has a good type inference system, but it insists on a unique type for each object (which includes "null"; a type of "str or null" is not acceptable). The rest of Shed Skin, outside the type inference system, is not very well developed. There's a path there to a fast Python with some restrictions. The Shed Skin inference engine with the Cython engine might have potential. PyPy gets some speedups, mostly by recognizing when numbers can be unboxed. (CPython carries around a CObject for every integer; that's what's meant by "boxing") But outside of number-crunching, PyPy doesn't show big gains. And the whole PyPy JIT system is far too complex. They try to retain all of Python's dynamism, and as a result, they need to be able to bail from compiled code to one of two different interpreters, then recompile and go back to compiled mode. Unladen Swallow failed to produce much of a speed improvement and Google pulled the plug. It's time to look at alternatives. There's no easy way to speed up Python; that's been tried. It needs either a very, very elaborate JIT system, more complex than the ones for Java or Self, or some language restrictions. The main restriction I would impose is to provide a call that says: "OK, we're done with loading, initialization, and configuration. Now freeze the code." At that moment, all the global analysis and compiling takes place. This allows getting rid of the GIL and getting real performance out of multithread CPUs. John Nagle -- http://mail.python.org/mailman/listinfo/python-list