[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