The Redecorator
Dec 21, 2004
I hate decorators. Although they have a few valid uses, I think they're almost always the wrong design choice. In fact, on Friday, after reading Ian Bicking's blog entry about them, I began writing a long rant about why they were usually a poor choice.
It was at this point that I realized that I'm not good at writing rants. It's just not what I like to do.
However, I do like to write Python - so I thought of a way to register my displeasure with our new language feature. The idea was so simple that I knew I had to do it. I would negate decorators.
The Redecorator is a fairly simple script which utilizes the fact that decorators are merely simple typographical operators to negate them. It takes a python source file as input, and produces another as output. The output file should be stripped of decorators, but be functionally equivalent to the input file.
Although it's fairly simple, it ended up being longer than I thought it would be. The Redecorator currently stands at 117 lines, most of them code. It is not production code; I've only tested it on a really simple test file. It will likely bork on files with mixed tabs and spaces (but you shouldn't have those anyway, you know). It's only been tested on Linux, but it should be cross-platform.
You can get the code here and the file I used to test it with here. I run it with: ./redecorate.py < dec_test.py > dec_out.py , but it can take files for input and output. Read the docstring.
Rant (this is not a rant)
Writing this script actually taught me quite a bit more than I thought it would. It forced me to read the PEP for decorators, which convinced me (grudgingly, and on my third time through) that there are valid uses for decorators. I now know in what order decorators are applied, and exactly (I think) what they really do.
However, I still think that uses like Ian's are incorrect uses of decorators. Unless a decorator significantly simplifies a function, I don't think that it should be decorated. In his blog entry, the first solution is simple, direct, and to the point; the second solution is impossible to understand without much more thought than it deserves.
What, then, are valid decorators? That's a matter of opinion, naturally. I think that staticmethod and classmethod are good uses of decorators, and this decorator seems to really simplify what could be an otherwise complicated function.
I still do not feel that these use cases are significant enough to warrant inclusion of decorators into python. They don't do enough to merit the confusion that they will cause new programmers when they first encounter them. As always, though, I'll live with it, because I think in python by now.
Finally
This is not a rant, despite the brief section above. I'm not a good writer, and I haven't fully sketched out my thoughts on decorators. Think of this post as my bit of civil disobedience in the python world. Think of it as a plea for simplicity in the language I love so much.
Please leave the decorators to other people, and write your code without the sugar. Make the world just a little bit simpler.
Update 12-24-04: fixed handling of multiple decorators. Merry Christmas!
[# ▷] redecorator, python, programming, decorators
