[pypy-dev] Re: appspace considerations and genrpy

Christian Tismer tismer at stackless.com
Thu Dec 2 00:12:44 CET 2004

Hi Armin,

>>If you look at md5.py, you'll see that it *is* already almost
>>restricted Python. I can just move almost all functions
>>over to the interpreter level.

But not by hand :-)

> Yes, only some code is "essentially" application-level code.  Some other code
> is quite "C-ish" already, and doesn't in any essential way need to correspond
> to space.xyz() calls.  It can just "do its job" and return a result.


> In this respect md5.py and sha.py are similar to _formatting.py: they are all
> general Python code (so meant for app-level) that is almost RPythonic enough
> that we could put the code at interp-level with only some amount of uglifying.


> Didn't your mind go a full circle back to its starting point?  I seem to
> remember that you started work on genrpy precisely to avoid to uglify
> _formatting.py by hand.  Now you say that md5.py should better be put to
> interp-level manually...

No no. I'm getting further. I'm trying to figure out what
can be just taken as is, as interpreter level code, and what
needs to go into app space calls.

I'm just not really decided what's right.
I can start as I started: everything is a space.wrap of a
space.whatever, and we need to have another simplification step.
The alternative is to try to keep code as it is, if it is
rpythonic, and just to identify the operations that RPython
doesn't have, only wrap these, call the space, and immediately
unwrap the result.

This happened to me, when I saw that md5 is just already in
shape togo into interp level, just a little class thing is needed.

> While this is of course possible, the idea of genrpy was to do it
> automatically.  I know the generated code must look incredible right now,
> because it's just calls to space.xyz(). 

Yes, and I have a simple problem running the stuff:
What do I do over the space, and what do I directly?
I think my generated functions should not be called
via space,since the interface is interplevel,already.
The things which I don't translate are those which
use the space calls. Right?

> But the idea is to run the annotation
> stuff over the graphs -- which assumes some restrictions, which are generally
> fine for the kind of app-level code we are considering.  Then genrpy can be
> extended to use the annotations, e.g. when it knows that a given variable is
> an integer, it should use a real integer in the produced code too, instead of
> a space.wrap(value), and real '+' '-' etc operations instead of space.add(),
> space.sub(), etc.

SO what you are saying is that I don't careand just translate
away? I thought it is a waste for stuff which is perfectly
interplevel already, and I'd like to find this out and
avoid translation.

> In this way we produce interp-level code that will be:
> * unreadable
> * fast
> * automatically integrated with the rest of the interp-level code
> * still containing some space.xyz() operations if needed -- i.e. we can still
>    use app-level code as a "macro language" to compactly write things like
>    space.is_true(space.eq(space.getitem(w_list, space.wrap(i)), w_value)).

Ok. But another thing that annoys me is that this macro language
still has rpythonic restrictions, when I use the unmodified
flow space. I think it should be full Python.
I had the strong feeling that I did a whole mess with no real
benefit. But I might be wrong.

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