[Python-Dev] Class decorators

[Phillip J. Eby]

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, db_id=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.