[pypy-dev] opcodes bundled in a class?

holger krekel 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 
whatsoever. 

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

cheers,

    holger


[*] 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 
    app/global/visibility concept. 


More information about the Pypy-dev mailing list