Decorators: an outsider's perspective

[Chas Emerick]

I thought I'd finally break my lurker status here by passing along a 
comment I made in connection with this weblog post 
<http://zephyrfalcon.org/weblog2/arch_e10_00610.html#e610>, one of many 
deriding the controversial feature of @decorators.  Feel free to flame 
away, especially if the regulars here think I'm beating a dead horse 
:-):

By no means am I an expert in Python (I get paid for writing Java, 
although my hobby projects have been in Lisp over the past few years), 
but this @decorator flap has made no sense to me at all.

The best argument against the new syntax is that it will impede noobs 
(like myself, I suppose) from picking up the language. I think nothing 
could be further from the truth, for one reason: action-at-a-distance 
is *always* bad.

The first time I saw this, I almost fell out of my chair:

def blah (args):
....[insert 50/100/200 lines here]
blah = staticmethod(blah)

That's BAD. That, my friends, is tough to wrap one's mind around, for 
the exact reason that, unless one reads through an entire module, the 
critical staticmethod call might not even be seen. That's a pretty 
devestating blow to the ability of a noob (or hell, anyone for that 
matter) to learn what's going on in some code.

So, when I see:

@staticmethod
def blah (args):
....[insert 100 lines]

I say, YES! Sure, decorators can get complicated, as exemplified by 
some of the examples provided in the post. However, just because 
something is complicated, or even not the greatest approach in some 
cases, doesn't invalidate it. Take recursion: a concept and practice 
that noobs trip over almost as a rule, and an approach that is 
constantly abused and overused in inappropriate situations. However, 
that surely doesn't mean that recursion should be disallowed, or 
scorned even. It means it should be respected, taught well, and used 
when appropriate. Decorators surely fall into the same category.

Regards,

Chas Emerick