[pypy-dev] Re: appspace considerations and genrpy
arigo at tunes.org
Sat Dec 4 18:01:40 CET 2004
On Thu, Dec 02, 2004 at 12:12:44AM +0100, 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.
> But not by hand :-)
Well, that's a difficult problem, then: can we figure out automatically the
proper interface to use md5.py as interp-level code? Maybe. This would be
similar to the kind of hacks done in gateway.py: we could have a gateway
function that inspects a class and generates an app-level class that is
essentially a collection of built-in methods to access the original (now
At a first glance this is independent from any translation stuff. It is
independent from the other approach where we want to port code with some
"essentially" app-level parts, which have to become space.xyz() calls. This
was what I described: assume the app-level code is still fully RPython, pass
it through the translator/annotator, and generate interp-level code from that.
Now maybe there is a way to combine both approaches. Automatically? I don't
know... We probably need a concrete example of both approaches before we can
tell how to combine them for a 3rd concrete example.
So probably both the inspect-to-generate-interface approach of gateway.py and
the analyse-and-regenerate-everything approach of genrpy.py are worthwhile to
> 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.
Well, so far, a number of app-level helpers and modules are really full
app-level Python, but there isn't much optimization we can do with that, at
least without Psyco. The best I can imagine would be to turn the code in a
series of space.xyz() calls and do some kind of local type inference to see
what types can be known for sure -- but in my opinion that's a waste of time
because very few types can be known for sure.
More information about the Pypy-dev