Aktuelle Änderungen Printable View Änderungen Bearbeiten
StGB > IDEs > IDE > Diff > Meta > JSON > Nice > Lisp > ManU > CLOS > CommonLispObjectSystem > REPL > ReadEvalPrint > Wiki > Guru > Java > PyPyClear TrailPython is fun and useful, but it really isn't mature until PyPy is released for production use. <7x1x8el18e.fsf@ruckus.brouhaha.com>
we got to the point where PyPy basically runs on its own, after whole-program type inference and translation to C
Think of Psyco as a kind of just-in-time (JIT) compiler, a little bit like Java's, that emit machine code on the fly instead of interpreting your Python program step by step. The difference is that Psyco writes several version of the same blocks (a block is a bit of a function), which are optimized by being specialized to some kinds of variables (a "kind" can mean a type, but it is more general). The result is that your unmodified Python programs run faster.[1]
Sooner or later Python will go the LISP way of having a standardized "Common-Python" (std_objectspace) and a number of dialects and DSLs running in their own derived object spaces. <1115791624.856252.247890@z14g2000cwz.googlegroups.com>
In short, PyPy has already taken the most important step for us to escape from the CPython "gravity well" of needing a backward-compatible C API.
As a simple example, PyPy can generate threads-supporting and non-threads-supporting versions of itself, refcounting and garbage collection versions of itself, and so on. Essentially, PyPy is completely virtual with respect to the underlying VM, even though it uses CPython bytecode. So, in the next few years it will be possible to experiment with radical redesigns of the VM, without getting bogged down in the "last 20%" issues experienced by projects of the past. Heck, it should be possible to use custom-tuned VMs on an application-by-application basis!
With any luck, we may yet see PyPy become the One Python to Rule Them All, replacing CPython, Jython, and IronPython with C, Java, and C# translator backends respectively.
"Native compilation" is not a very interesting or useful goal. The real underlying goal is efficiency, and naive native compilation of Python to C (which has been done probably a dozen times so far) doesn't buy you that.
For a language with the characteristics of Python, dynamic translation in the tradition of Self and Smalltalk is the way to go. The PyPy guys are indeed working on this and have brought their own sizable bag of tricks to the table. For example, Armin Rigo, the developer of Psyco, is one of the head PyPy honchos; I understand that the ObjSpace concept in PyPy was largely inspired by Armin's experiences in implementing Psyco, which "partially specializes" the interpreter at run-time by dynamically outputting and executing x86 code.
pypy provides infrastructure for building interpreters in [r]python. This infrastructure makes it much easier than starting from scratch, e.g. by providing reusable components for language runtimes (like GC's). [2]