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. 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? > 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. > Regarding the grammar, I have no strong opinions, although using the > 'class' keyword, as in "super(class,self)" has a nice ring to it. I'd like something decoupled from the super() function, so you can use it for normal inherited calls as well. Not sure what, though. -- Greg _______________________________________________ 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
