[pypy-dev] Re: appspace considerations and genrpy
arigo at tunes.org
Wed Dec 1 23:15:18 CET 2004
On Thu, Nov 25, 2004 at 09:04:18PM +0200, Christian Tismer wrote:
> 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.
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
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(). 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(),
In this way we produce interp-level code that will be:
* 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)).
More information about the Pypy-dev