Collected Responses to Comments on "The Redecorator"

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.