[Python-3000] A super() idea - no _getframe() involved

[Phillip J. Eby]

At 07:20 PM 4/19/2006 +1200, Greg Ewing wrote:
>Phillip J. Eby wrote:
>
>>That is, it defines the function with MAKE_CLOSURE instead of 
>>MAKE_FUNCTION.  It also puts a reference to the cell object in the 
>>class's dictionary, let's say under __cell__.
>
>Presumably it would first check if there was already a __cell__
>put there by another function and use that.

No, the compiler does it, it's not an execution time thing.  That is, the 
code object is set for a certain number of "cell vars", and that's what 
allocates the cell object when the code is executed and the frame is set up.


>What happens if the function gets wrapped by a decorator? I
>suppose it still works, because the cell remains attached to
>the innermost function where it's needed, right?

Right, it's part of the function object's func_closure tuple.


>>Or perhaps the 'type' constructor takes care of this, but if we can have 
>>class decorators it might be better to have MAKE_CLASS do it so it always 
>>points to the object that *will* be bound to the class name in the 
>>enclosing scope.
>
>Isn't that backwards? MAKE_CLASS is going to bind it to the
>class created by the basic class statement, before the
>decorators get to work on it. The object returned by the
>decorators might be something different.

Sorry, I was thinking of PyProtocols/zope.interface style class decorators, 
which work by metaclass munging.  That probably means that the scope 
enclosing the class should define the cell, and have a stanza like:

     MAKE_CLASS
     ... decorators, if any ...
     DUP_TOP
     STORE_DEREF __cell_for_this_class__
     STORE_NAME  "classname"

And this way, it doesn't need to be an attribute of the class object.