Collected Responses to Comments on "The Redecorator"
Dec 22, 2004
Phillip J. Eby writes:
the issue with his use of decorators (to me anyway) wasn't that he used them, but that he had a really silly name for the decorator. Instead of @param, it should've been called something like @call_with or @test_with. Then, the code would have made more sense when reading.
While I agree with your point, Phillip, I still feel that there's a greater issue at hand. I don't think that Ian's use of a decorator to create a testing function is simpler than the alternative he prevents. Thus, I don't think that he should use a decorator in that circumstance.
With properly named and documented decorators, it shouldn't be necessary to understand their implementation
I've always had problems with this theory. Know the interface, and assume that it works by "magic", it says. While that's fine in theory, I find that I am far less effective when I use a framework or interface and not what goes on behind it. It may just be that the way I think requires me to understand the underlying technology in a way that other people don't need to, but I am just not comfortable using an implementation of something I don't understand.
Obviously, there have to be exceptions, as some things would require an indordinate amount of effort to understand deeply. While I allow that this is sometimes true (CPython and wxWindows come to mind), I work hard to increase my understanding of the underlying technology every time I get a chance to do so. I find that the more I know about it, the better my code gets, and that I often get "aha!" moments as I grasp more of the framework.
Furthermore, it seems to me that this statement is less true in Python than in Java, as Python allows extraordinary simplicity. This is one of the main reasons why I like the language, and this is one of the reasons I dislike extensions to it which encourage complexity.
Fredrik writes:
I'm beginning to realize that the people who are the most enthusiastic about things like metaclasses, decorators, nested-functions-instead-of-classes, etc. do not think in the same Python as I do
I don't know if I'd state it quite that strongly, but I do see a new trend in the way that people want to use python. I find myself using nested functions, but very occasionally, and only in limited circumstances. I mainly find them useful in mathematical contexts.
What scares me is what I see as the c++ification (if I may coin a term) of our language. The community seems content to move towards adding language features that are useful only to the wizards of the language. This is fine for the wizards, but it tends to create a second class of programmer. These second-class programmers, who just want to get things done, understand the basics of the language, but simply assume that code which contains metaphors they don't understand is unreadable.
I think that metaclasses (which I just assume I don't understand, myself) and decorators (which required me to waste a lot of time just to understand how simple they are) are both steps down this road, unfortunately.
Tim Lesher writes on his blog:
My only, weak answer [to "why should I use a metaclass?"] was, "If you think you need one, you don't. If you know you need one, why are you taking advice from me?"
That is exactly what I meant to say when I asked people to leave decorators to the Other People. The set of features that require this sort of response is almost exactly equivalent to the set of features that I don't like.
Finally, Bob Ippolito, who really should pick pyblosxom for his new blog server (/marketing), writes:
Personally, I think that decorators serve a useful purpose. There are many cases where they save you from spelling out an identifier three times. Repetition is stupid, and Python doesn't otherwise have a lot of repetition, but function transformations need them since functions are statements and not expressions.
Maybe I should just use lisp instead.
In my mind, simplicity is a greater goal of python than is the avoidance of repetition. GvR has often made it clear that limiting the number of keystrokes is not one of his guiding factors in desiging the language (" This is *not* a number-of-keystrokes argument. You know I don't care much about that."). I'd rather see him choose simplicity over features which remove keystrokes at the cost of added complexity, unless the feature adds a lot of power. I don't think that decorators meet this criteria.
A lisp master's code might do something complicated in 10 lines, while it takes a Python wizard 25. However, it is a hell of a lot easier for a person with only a moderate understanding of each language to figure out the python wizard's code than it is for him to understand the equivalent lisp code (IMHO, naturally). This is a feature of Python that I like.
Wizards can have their lisp, I'd rather save my limited brainpower for getting things done in a readable way, even if it's not in the fewest lines of code possible.
[# ▷] meta-blog, python, decorators, lisp, metaclass, responses
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
