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

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 MAKECLOSURE instead of MAKEFUNCTION. 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 MAKECLASS 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? MAKECLASS 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.

More information about the Python-3000 mailing list