[Python-Dev] Class decorators (original) (raw)

Phillip J. Eby pje at telecommunity.com
Thu Mar 30 03:43:41 CEST 2006

At 08:00 PM 3/29/2006 -0500, Jack Diederich wrote:

A function decorator takes a function as an argument and returns something (probably a function and maybe even the very same function).

So would class decorators.

This is exactly what class decorators should do or we should call them something else and give them a distinct syntax.

Yep.

A function decorator is there to replace code like:

def myfunc(a, b, c): # half a screen of code myfunc = mangle(myfunc) Likewise class decorators would save me from typing class MyClass: # many functions taking half a screen of code each register(MyClass, dbid=20)

Yep.

Talking about something other than a decorator

You lost me there. Nobody's argued (AFAIK) for class decorators being anything other than single-argument functions that take a class as input and return a class as output.

or proposing all new syntax is just going to get this pronounced out of existence.

Which wouldn't be a bad thing, IMO. There's no point in adding them if they're not an actual improvement over what we can do now.

Comments about the hackishness of the implementation used by Zope and PEAK are also off-base; nobody proposed that everyone should go off and implement their own such hacks! Meanwhile, inclusion of such a facility in the stdlib isn't without precedent; there are IIRC at least 6 sys._getframe hacks in the stdlib already. Nothing stops us from adding a 'decorate_class' function to the stdlib that's used like this, for example:

class MyClass:
    decorate_class(
        register(db_id=20),
        implements(IFoo),
        ...
    )

or to just make the class machinery interpret a decorators attribute (a variant on an old suggestion of Guido's):

class MyClass:
    __decorators__ = [register(db_id=20), implements(IFoo)]

The only implementation reason to give this special syntax, IIUC, is to allow implementations like Jython and IronPython and Pyrex to statically recognize certain decorators at compile-time.

There are of course also non-implementation reasons to have class decorator syntax (such as EIBTI), and I agree with that. But readability also counts, and the readability of @decorators on the outside of a class tends to suck as the number of decorators and arguments increases.

What's more, I haven't seen anybody posting any counterexamples to show that it doesn't suck for common use cases. Indeed, at the moment I don't even recall seeing any examples of class decorators being used without arguments! I also suspect that any actual Jython/IronPython examples are likely to be at least as verbose as Zope and PEAK's, and probably more likely to include multiple decorators. (Depending on how Java annotations and .Net attribs would be translated to decorators.)

So, I'm personally not in favor of adding class decorators with a syntax that blindly imitates that of function decorators, without a proper examination of the use cases. This is precisely the argument that Guido used to veto class decorators in 2.4, and nothing about the issue has changed since then, except for the subject being reopened to consideration.

More information about the Python-Dev mailing list