Plumbing Life's Depths - Decorators for classes and methods/functions...

Decorators for classes and methods/functions...
Written by Mike on March 2, 2004 in Snaking.

Alan Green has some comments on PEP 318 up on his Blog. I've seen the PEP a few times so far, and as of yet, I've never been particularly happy with it. It's not that I think it's horribly ugly, it's just that it doesn't seem particularly elegant.

Comments

Bob Ippolito on 06/25/2004 8:29 a.m. #

Classes were never the big reason, the big hit was always method decoration.
Mike Fletcher on 06/25/2004 2:03 p.m. #

Which wouldn't seem to alter anything. You call a method/function and it has lots of unexpected side-effects. It becomes part of the language you need to understand to debug someone else's code. Not a huge issue, but it does expand the language, and one of Python's great strengths is that it's a *small* language. We don't have to *stop* advances, just be careful not to get too much magic migrating into the core. 
 
How many built-in decorators will show up, for instance (we already have classmethod and staticmethod)? Which ones will require imports (and thus pointers to their implementations to help the new user) and which will need to be understood before you can read any code?
Phillip J. Eby on 06/25/2004 3:19 p.m. #

Keep in mind that people today can and do use decorators anyway. Even multiple decorators. The only thing PEP 318 does is move them to the *top* of the function/method definition, where they'll be *more* visible than they are now. 
 
Also, as it turns out, anybody who really wants to can make top-of-the-method decorators now using trace function "magic". See this post: 
 
http://mail.python.org/pipermail/python-dev/2004-June/045583.html 
 
where I've basically let the cat out of the bag to let anybody create as many kinds of magic decoration as they want, as far back as CPython 2.2 and maybe further. 
 
Similarly, class decoration is also available today for CPython 2.2 via PyProtocols' "advice" module, which is also used by Zope 3 to declare interfaces.
Mike Fletcher on 06/25/2004 4:54 p.m. #

Oh, I'm aware of PyProtocols :) . To reiterate, though, metaprogrammers are responsible for making it easy for regular programmers to do their work. The language expanding has a cost: 
 
<pre>class X(object): 
def x( ): 
pass 
x = cool.coolmethod(classmethod( x ))</pre> 
 
only expands the language with "classmethod" being a built-in. Any basic Python programmer can see that the value x (a function) is being passed to classmethod, which will return some value, and then that value is passed to coolmethod, which returns some value, which replaces x. 
 
Understanding the effect requires you to look up what classmethod and coolmethod do, but there's nothing there that expands the language (beyond a builtin). 
 
<pre>class X(object): 
def x( ) [ classmethod, cool.coolmethod ]: 
pass</pre> 
 
The decoration itself is magic (i.e. a new syntactic construct that must be learned). The order in which decorators are applied is magic (and arbitrary). These are things the user must understand and know before they can debug such code. 
 
To reiterate, I'm not saying "don't do that", I'm saying "Keep in mind that each new language feature that must be learned makes Python less small, and that small is *good* in languages, so make sure you get the maximum benefit from each such change. Be prepared to invest in educating old Python coders and to need more education for new coders."
Artur de Sousa Rocha on 06/27/2004 1:32 p.m. #

You verbalized what I instinctively always felt about the new decorator syntax. I'm ready to accept the after-parens syntax if it's introduced, but I too feel that the "process" of decoration should rather be explicit in the code. 
 
Surely one could argue that list comprehensions are cryptic as well, and that PEP 318 adds to the brevity of code in a similar way. But I think "trick syntax" should only be available for the most frequently-used and easy to understand concepts.
iio on 06/27/2004 1:39 p.m. #

I somewhat agree that "[static, checked, moved, databased, fluffed, vindicated, lofted, restorable]" is bad, but i strongly disagree that "a new syntatic construct that must be learned" is bad. Syntatic constructs are very easy to learn (unless they have lots of exceptions and special cases or have several overloaded forms, as in Perl's {}, <>, etc.). The problem users will face is: "How can i use this feature intelligently?" or "What do that rarely-used decorator do?".