[pypy-dev] RPython, PyPy, Stackless and all the rest (was: Branch merged)

[Christian Tismer]

Armin Rigo wrote:

...

> * Christian: we did not completely port your r19917 because it needs
>   some adaptations to the new world.  The Translator class is being
>   replaced by a much thinner TranslationContext.  Most importantly, your
>   changes to translator/c/pyobj.py haven't been merged -- they will also
>   need adaptation to work on graphs instead of functions, as we did for
>   the rest of pyobj.py.  It was also difficult to know exactly what was
>   needed because of the absence of tests.  However, there is a tag of
>   the trunk before we merged, so that a working pypy with your changes
>   is still in http://codespeak.net/svn/pypy/tag/dist-ext-someobject .

That's fine with me. I didn't consider my patches more than a
quick hack to get things going, and the major purpose was to
hack in what was needed, just to convince the EWT people that
PyPy is the way to go for their future (which worked very well).
This part of code generation (concerning extensions and how to
handle certain external objects) was kind of under-developed
all the time.

After my initial tests, I have a better picture what's needed,
and I would like to discuss a couple of ways to create a nice
interface for building extension modules, and also new builtin
modules! This is because after a while of thinking, I figured out
that this is the best way to support hard-to-port things like
Stackless Python ATM:

Instead of again patching all the newly grown extension modules
to support some half-hearted Stackless support, I want to build
a Stackless-PyPy hybrid implementation, based upon CPython 2.4,
but with certain modules removed from the source and replaced
by PyPy generated source code. This source code will be generated
from RPython implementations, which are then both used in PyPy
and in Stackless. One example of these should be the itertools,
another one the Stackless module itself (and of course the
new deque objects, which I ported to RPy in the states,already).

With this approach, I hope to make PyPy productive right now,
before we have the advanced technologies, to simplify porting
new features to Stackless, and to make more companies interested
in using PyPy for their code.

I have a sack full of small features which are needed for this.
Nothing too hard, but enough for quite some work. I think it
makes sense, because PyPy becomes productive right now, and we
need that to have an argument for being used in production code.

cheers -- 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/