[Python-Dev] Class decorators
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, 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.
More information about the Python-Dev
mailing list