Carl Friedrich Bolz wrote: > Luis M. González wrote: ...
>> So we will have two choices: >> 1) running normal python programs on Pypy. >> 2) translating rpython programs to C and compiling them to stand-alone >> executables. >> >> Is that correct? > > Indeed. Another possibility is to write a PyPy extension module in > RPython, have that translated to C and then use this in your pure python > code. Actually, one of our current rather wild ideas (which might not be > followed) is to be able to even use RPython to write extension modules > for CPython. Actually, this wild idea is mine, but PyPy may share. :-) And there is no need for this to be followed, since I'm going to do this anyway, because I have good personal reasons: There is a lot of demand to get Stackless ported more easily, and the current way of manually fighting the ever growing number of C modules by hand just sucks. Waiting for PyPy to get mature enough to replace Stackless is one way, which takes too long. Waiting for "readyness" of PyPy to produce something ahead of explorational and toy interpreters is also no option, although these are very nice and great for education. My alternative is to use translation of RPython to produce extension modules for CPython. Although this is considered an "implementation detail" by most of the PyPy core people, companies which are considering to write extensions in C are just finger-licking for such a detail to use, instead. I will use it for Stackless Python as a show-case. As an example, I want to revert itertools and dequeues to almost their Python equivalent and then translate them into C using PyPy's translator. While this is of no visible worth for the normal Python user, it gives me the advantage that these modules will gain support for the Stackless features automatically, because the base support is built into PyPy. This is not trying to split apart from PyPy, or to short-cut its goals. I'm completely with PyPy's goals, and it will do much more than RPython translation ever will, this is out of question. One problem is that we cannot produce a competitive Python implementation by now. There is a lot more work involved to gain the necessary speed to be considered. On the other hand, the produced low-level code for builtin objects is already almost as efficient as hand-written code in many cases. As a proof of concept, I have used this to turn an application program into compiled RPython, which became over 10 times faster and outperformed its highly optimized Java counterpart. I just believe that RPython is a piece of gold, a gem created aside while trying to build the huge thing, and we should not leave its potential unused. Sure, it needs some processing and finishing to make it easier to use and have better support for interfacing to existing CPython objects. After three years, the PyPy project can really take the chance to produce a small, useful tool for the ambitioned developer. Not making his task trivial, as PyPy will, but considerably simpler than writing C. merry christmas -- chris -- Christian Tismer :^) <mailto:[EMAIL PROTECTED]> tismerysoft GmbH : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9A : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ -- http://mail.python.org/mailman/listinfo/python-list