> Decorators are somewhat of a pain because there is a difference between @foo and @foo(). If they were declared in a way that the former means the latter we would all be much happier now. Every time I want to introduce a parameter to a previously parameterless decorator makes me want to hit myself and the author of the decorator PEP with a stick.
http://lucumr.pocoo.org/2011/7/9/python-and-pola/
Discussed on HN too:
@a[1]
def f(x):
...I had a permission checking decorator that I allowed both syntaxes (the default permission check and a mre fine-grained check). The flaw makes for an ugly implementation.
you can see what i mean here - http://code.google.com/p/lepl/source/browse/src/lepl/matcher...
this doesn't fix the problem completely, of course, but it does mean that a user that types @foo instead of @foo() gets a helpful warning explaining exactly what they have done wrong.
def decorator():
return some_library.decorator_with_no_args
@decorator()
Also, I wish they would integrate some of the stuff from this answer into the documentation, as it took me almost an hour to figure out how decorators that take arguments work and to discover that @decorator and @decorator() are irrevocably different. The documentation I found on decorators that take args was very brief. (I can't remember if I found any mention at all in the actual Python docs. I ended up learning it from mediocre, old blog posts)