[pypy-dev] opcodes bundled in a class?
hpk at trillke.net
Tue Aug 5 11:08:13 CEST 2003
[Armin Rigo Tue, Aug 05, 2003 at 12:00:30AM -0700]
> Hello Holger,
> On Mon, Aug 04, 2003 at 07:47:27PM +0200, holger krekel wrote:
> > 'ScopedCode' was not meant to be such a plain code object. It's rather wrapping
> > a plain lexical code object (the cpy one) and tying it into a context of scopes.
> Then it is a function object...
really only if you pass arguments. There are code objects that are
simply executed in a context of scopes - no argument parsing stuff
> > Maybe the name 'ScopedCode' is not perfect but without this concept you
> > have a lot of boilerplate at various places dealing with code objects
> > and scopes. To me it seemed that the steps
> > 1. tying a code object to certain scopes
> > 2. creating the frame / possibly parsing arguments into locals
> > 3. executing the frame
> > are a useful separation of concerns.
> Indeed. As far as I understand it, (1.) was the reason why Python has separate
> notions of code objects and function objects. It is even clearer in CPython,
> where function objects are not built-in functions but really nothing more than
> a code object tied to a certain environment.
Hmmm. i think we have two cases for interpretation:
1. code objects, tied to a scope, executed (modules, exec statements ...)
2. function objects, tied to a scope, parsing arguments, executed/interpreted
the design in gateway.py was meant to fit this model and because
they share functionality 'InterpretedFunction' derives from
'ScopedCode'. Of course we could declare 1. as beeing a degenerated
function (with no argument parsing) but somehow i felt that 'scoped
code' objects are the real "one" building block. I wouldn't think
of 'module code' execution as executing a 'function'.
However, Armin, please feel free to just modify the branch so that it more
suits your view. I don't think that we are far away from each other [*].
The real challenge probably is how to handle globals:
how do app-level functions/data see each other?
I would (try) approach this in a static way (rather than the very dynamic
way i understood from our IRC discussions), e.g. construct a
w_globals for every module and put all app name-bindings in
there once and for all. For builtin-modules the globals should be on
the class instance. Again, feel free to design this differently.
[*] please note that 'InterpretedMethod' is just a hack for unittest_w because
all the app-level unit-tests still have this (currently) useless 'self'
argument. I didn't want to change all the tests unless there is a
More information about the Pypy-dev