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.
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
