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...
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. It is essentially just a question of terminology so far, but then if 'ScopedCode' is actually a function object (which I guess you knew from the start, but I never actually understood that), you should consider that we thought about defining only a single function type in PyPy and varying just the code object types to reflect the different kinds of implementation. In gateway.py, on the other hand, you have created a whole hierarchy of subclasses of 'ScopedCode' (some with 'Function' in their name -- I really should have understood it earlier). All these classes' instances have a 'cpycode' attributes, but some subclasses expect it to be a code object with an interpretable bytecode. (BTW these ones have the 'cpycode' attribute repeated under another name, 'func_code'.) When we talked about having only one function type, the goal was to have a hierarchy similar to the one in gateway.py but with code objects instead. The (single) function class would only have the issues that do not depend on the kind of code object used for the implementation, mainly argument parsing. A bientot, Armin.