Hello Holger, On Mon, Jul 28, 2003 at 02:26:18PM +0200, holger krekel wrote:
with the builtinrefactor branch i am at the point where i want to eliminate the 'appfile' concept alltogether in favour of intermingling app-level and interp-level code directly.
(...) However, is anybody against putting the opcodes/helpers in a class?
As we discussed the other day on #pypy, there are in my opinion two different issues in your mail: how to get rid of the *_app.py files (including how to expose interpreter structures to app-level), and whether the opcodes should be moved into a class. Currently the second issue is (also) motivated by the fact that the code in the builtinrefactor branch can only mix app-level code as methods of an instance that have a 'space' attribute -- hence the push to make opcodes into a class. (Let me discuss the *_app issue in the next mail.) Independently of this problem I guess it is a good idea to make a class with the opcodes, instead of just a module like it is now. I'd even say that it should simply be a subclass of PyFrame, with PyFrame being an abstract class that has the logic to load and dispatch opcodes from a bytecode string but not the actual implementation of individual opcodes. In my point of view *code objects* are interpreter-level classes which are not tied to a particular object space (they are "lexical objects", i.e. essentially the same as the source code they represent); then a *function object* is a code object bound to a particular environment, i.e. with an object space, with default arguments, maybe with a closure for nested scopes, and so on. The function object, when called, creates a *frame object* and execute it. In PyPy there is only one function type, but several code object types: standard Python code object (app-level source code), built-in (i.e. implemented at interpreter-level), and possibly others like "using my own special opcodes". In this point of view, you can only call a function object (not a code object), but the function object needs to call a method build_frame() on the code object to create the appropriate kind of frame object. The resulting frame object should then have an eval() method to be actually run. I'm not sure where exactly the ExecutionContext comes into play; its role is to store the frames in the frame stack, but in Python built-in functions do not register frames there. Maybe it should be the role of the specific PyFrame class (implementing an app-level frame) to register and unregister itself into the frame stack. And what about generators ? I guess it would be nice if built-in functions could act as generators as well. A bientot, Armin.