[pypy-dev] Re: Comments from an observer

Christian Tismer tismer at stackless.com
Fri Dec 9 14:58:22 CET 2005


Carl Friedrich Bolz wrote:

> RPython is not good for making a lot of Python programs amenable for 
> analysis for several reasons. One of them is that although RPython is a 
> rather nice and powerful language is *is not Python* (although it 
> deceptively looks like it). That means (as Michael already pointed out) 
> that it is really hard to convert an existing program to RPython since 
> the style of programming is just totally different.

It is true that itis hard to concert an existing program to RPython,
but it is not about being a totally different coding style. The
kind of program one wants to convert to RPython is typically already
written in a style towards optimization.Of course, some optimizations
for Python are counter-productive in RPython, and the solution is
to remove them.

You will see what I mean when I do my presentation, tomorrow.
Most what I had to do was to avoid type ambiguity, and to avoid
features which we don't support, yet. But finally, the programs
don't look so different. Partially, they even do look better,
because RPython lets us use constructs, which you cannot use
in Python, due to current speed limitations.

For instance, for accessing certain pieces of data (talking of
a simple parser I'm going to show), Python programmers tend to
write string slices explicitly, using constants and optimizing
their expressions by hand.
This kind of optimizations makes Python programs much less
readable and reallyraises the questions why they
don't better write an extension.

With RPython, I don't need to do any of this. Instead, I can afford to
write tiny classes to be wrapped around the data I want to analyze,
creating a much nicer, more readable and configurable source.
This is due to the fact that with constant evaluation and inlining,
all these tiny instances are melting away and producing the same
high quality code as you would get by explicitly writing slices.

> So all the people 
> saying "yay, I want RPython to speed up my program" will run into deep 
> problems, no matter how much the RPython toolchain will be brushed up. 
> After all, the PyPy standard interpreter was written in RPython from the 
> ground up.

I am addressing people who are already looking into writing extension
modules. Giving them RPython as a tool to generate this extension
module instead of hand-writing it is incredibly valuable.
I do agree that this is not a cake walk, and I'm not going to try
to make a tool that lets people do this with just any program,
automatically. It makes sense to make RPython debugging easier
and to get more help out of the tracebacks. Finally I'm not trying
to compete with PyPy. Translating real Python is what PyPy is for.
On the other hand, there is no point in forcing extension writers
to continue their tedious work, after RPython exists.

> The other problem is that you have nearly no standard library available 
> in RPython, which is also something that is not easy to change. And it 
> is easy to forget just how much most python programs are dependent on 
> the stdlib :-).

Again this is not true. I can use all of the Python libraries
from RPython,although I have to write some support code fir this.
We wil end up by creating a new object space, which is able to
give an abstraction of the existing CPython. There is quite
some work to be doneto make this work smoothly.

For sure it makes not much sense to use RPython stand-alone.
Instead, I'm heading to build extension modules which can
call back into any Python code, like CPython extensions are
doing all the time.

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/



More information about the Pypy-dev mailing list