It may be time to standardize "RPython". There are at least three implementations of "RPython" variants - PyPy, Shed Skin, and RPython for LLVM. The first two are up and running. There's a theory paper on the subject:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.142.1457&rep=rep1&type=pdf All three have somewhat different restrictions: PyPy's Rpython: http://codespeak.net/pypy/dist/pypy/doc/coding-guide.html Shed Skin: file:///C:/Users/nagle/AppData/Local/Temp/shedskin-tutorial-0.3.html Rpython for LLVM: http://code.google.com/p/rpython/ So a language standardization effort, independent of CPython, would be useful. All attempts to make the dialect defined by CPython significantly faster have failed. PyPy did not achieve much of a speed improvement over CPython, and is sometimes slower. Unladen Swallow has not achieved a significant speedup, and is now a year behind on quarterly releases, indicating that the project is in serious trouble. PyPy's RPython, Psyco, and Shed Skin, on the other hand, all achieved order of magnitude or better speedups over CPython. So this is the way to go for higher performance. RPython may be the future of Python, a "golden middle way" between statically and dynamically typed languages. A basic concept of RPython is that it is declaration-free, like the CPython dialect, but limits the ability to change the type of an object at run time. Both PyPy's RPython and Shed Skin use type inference to determine the types of objects. PyPy's RPython has the best defined set of restrictions. Most of the restrictions are for speed, such as the unique-type restriction. A few simply reflect unimplemented features, such as generators. (Generators are not inherently inefficient.) A significant advantage of having a well defined set of restrictions is that it encourages writing Python libraries which will run under both RPython and CPython. This makes migration to a faster system much easier. John Nagle -- http://mail.python.org/mailman/listinfo/python-list
