Hi Christian, 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 future. > - 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. A bientot, Armin. _______________________________________________ [email protected] http://codespeak.net/mailman/listinfo/pypy-dev
