Hi Christian, 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 interp-level manually... 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(), space.sub(), etc. 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)). A bient�t, Armin _______________________________________________ [EMAIL PROTECTED] http://codespeak.net/mailman/listinfo/pypy-dev
