[pypy-dev] opcodes bundled in a class?

Armin Rigo arigo at tunes.org
Mon Aug 4 10:48:27 CEST 2003

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,


More information about the Pypy-dev mailing list