[pypy-dev] Re: genrpy is ready so far.
arigo at tunes.org
Tue Jan 11 19:07:21 CET 2005
Very nice work !
> First I think it needs a different name.
geninterplevel.py maybe ..?
Here's some more feedback on the questions as you put them in the source...
> - do we want to auto-generate stuff?
> - do we wantamoduleperapp-spaceoperation?
We should probably auto-generate the stuff, using the py.tool.cache mecanisms.
If we do so, then the files we generate should have a corresponding
granularity. I think that we can easily list all app-level helpers of the
same module (gateways know each others to be able to call each others). Then
we could translate one-module-at-a-time. With md5 checksums or whatever :-)
> - do we want to create code that is more similar to the app code?
I have mixed feelings about this. My initial reaction is "no" but then there
are use cases for the object space knowing a bit more about the names that the
interpreter gives to the objects... for example, for a debugging "history
object space" it would be convenient to record the movements within the local
variables too. Not sure how to do that or if the same thing can be reused for
the flow object space.
> - do we want to create specialized code for constants?
> - do we want to inline small functions?
I'd say no. That's the job of a future optimization pass.
> - do we want to use small tail-functions instead of goto?
Ack. You want to blow CPython up or force us to use Stackless to test genrpy
:-) But clearly, the ability to generate such code will be nice in the
> - do we want to translate non-rpythonic code as well?
Tough one :-) Maybe, using non-constant global dicts... but we need anyway
now to pin down precisely all simplifying assumptions that the flow object
space is based on, and document this as R-Python. This can be done
independently of the type-inferencing assumptions which are still in an fuzzy
state, but not related to genrpy.
More information about the Pypy-dev