[Python-3000] A super() idea - no _getframe() involved
Phillip J. Eby
pje at telecommunity.com
Wed Apr 19 09:48:22 CEST 2006
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
>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:
... decorators, if any ...
And this way, it doesn't need to be an attribute of the class object.
More information about the Python-3000