[Python-3000] super(), class decorators, and PEP 3115 (original) (raw)

Guido van Rossum guido at python.org
Mon Apr 30 21:17:53 CEST 2007

Hm... Where is the class decorators PEP? I was expecting it.

Assuming class decorators are added, can't you do all of this using a custom metaclass?

I'm not sure that your proposal for implementing an improved super has anything over the currently most-favored proposal by Timothy Delaney.

--Guido

On 4/30/07, Phillip J. Eby <pje at telecommunity.com> wrote:

While working on the generic function PEP, I came across an unexpected (to me, anyway) consequence of PEP 3115: it breaks current methods (circa Python 2.2+) of implementing class decorators. However, there does not appear to be a class decorator PEP outstanding.

In current Python versions, the only way to implement class decorators is to call a "magic" function in the body of the class, that inserts a special (temporary) metaclass to handle the decoration. This is implemented in the DecoratorTools package as well as in zope.interface (where its most common use case is to supply interface information about a class). Of course, in Py 3.x, some of these features could be handled using a metaclass with keyword arguments, due to PEP 3115. However, the other use cases cannot. Notably, any code that relies on in-class decorators or conditional class decorators (such as method decorators that add class decorators), will not be able to work. However, I have an idea for a small modification to PEP 3115 that would re-enable support for both static and dynamic class decorators, and make it possible to implement an improved super() as well. Suppose that we reserved a special name, 'decorators', that would be contained in the mapping object returned by 'prepare', and initialized to contain any static decorators defined outside the class, e.g., this code: @implements(IFoo) @otherdecorator class X: print decorators would print a list equal to [implements(IFoo), otherdecorator]. The idea here is that following the execution of metaclass(name, bases, classdict, **kw), the decorators list would be repeatedly popped to yield decorators to be invoked on the "finished" class. In this way, code that needs dynamic access to the finished class can simply add objects to decorators. As a result, we could then implement a super() enhancement of the form "super(class, self).methodname(args)", where "class" would be a compiler-defined variable (ala "debug"). If any function inside a class body uses "class", a preamble is added to the class body that defines an anonymous callback function that sets a closure variable to point to the class, and returns the class. This anonymous callback function is then appended to decorators. So, this approach could be used to enhance super() directly (using class instead of a specific class), or as a behind-the-scenes part of the implementation of a more "sugary" syntax. It would also continue to enable dynamic class decorators for other uses. Thoughts?

Python-3000 mailing list Python-3000 at python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/guido%40python.org

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-3000 mailing list