Please enlighten me about PyPy

[Christian Tismer]

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:tismer at stackless.com>
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/