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