[pypy-dev] opcodes bundled in a class?

holger krekel hpk at trillke.net
Mon Aug 4 12:08:02 CEST 2003


Hi Armin,

[Armin Rigo Mon, Aug 04, 2003 at 10:48:27AM +0200]
> 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.)

Please let me clarify the concepts behind the current builtinrefactor branch.  
The main point of the refactoring was to channel all calls to app-level code mainly 
through two classes:

ScopedCode:  a code object with a global and closure scope.
             you can execute ala 

             c = ScopedCode(space, cpycodeobj, w_globals, closure_w)
             c.eval_frame(w_locals)

             this is currently needed in many places.  Maybe it should
             be renamed to 'InterpretedCode' or so. 

InterpretedFunction:
             a function which will be interpreted at app-level. 
             it derives from ScopedCode and you can use it ala:

             f = InterpretedFunction(space, cpyfunc, w_globals, closure_w)
             f.create_frame(w_args, w_kwargs)
             executioncontext.eval_frame(f)

In fact there is a third in-between one, InterpretedFunctionFromCode, which
provides initialization from a cpy-code object rather than from a cpy-function
object. 

Therefore, the current builtinrefactor is not fundamentally requiring a 'space'
attribute and the 'app2interp' definition is trivial to change to your
suggestion (passing a space explicitely into app2interp-converted functions):

    class app2interp:
        def __init__(self, appfunc):
            self.appfunc = appfunc

        def __call__(self, space, w_args, w_kwargs):
            f = InterpretedFunction(space, self.appfunc)
            return f.eval_frame(w_args, w_kwargs)

with which you have from

    def app_f(x):
        return x+1

    f = app2interp(app_f)

the desired  explicit 

    f(space, w_args, w_kwargs)

interface.  IOW, app2interp is just a thin wrapper around the
lower-level machinery which was the real target of my refactoring
efforts and reduced the LOC's of the interpreter-directory by 10%
(more to follow).

> 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.

Yes, something like this.  Also see the other compiler-discussion, lately. 
(i am currently a bit in a rush ...).

cheers,

    holger


More information about the Pypy-dev mailing list