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:[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/ _______________________________________________ [email protected] http://codespeak.net/mailman/listinfo/pypy-dev
