6 ms·
Am I the only one who thinks it's a massive flaw that decorators that take args and decorators that don't are inherently different? That extra level of anonymou
by jackowayed 15y ago
Am I the only one who thinks it's a massive flaw that decorators that take args and decorators that don't are inherently different? That extra level of anonymous functions feels awful, and it's really confusing because a decorator that takes no args is @decorator whereas one that takes optional args is @decorator() if you just go with the defaults, and there is no way to make them both work.
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)
- jamii 15y agoIn your own code you can just wrap argument-less decorators in a function. def decorator(): return some_library.decorator_with_no_args @decorator()
- jackowayed 15y agoBut then @decorator doesn't work. I guess if I did that for every single decorator I use, I would at least have consistency. But that's not a very satisfying solution even ignoring the fact that now I have to wrap every zero-arg decorator I want to use.
- kbd 15y agoArmin Ronacher (prominent Python developer) included a critique of decorators in a post about a month ago making precisely your point: > 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/ http://lucumr.pocoo.org/2011/7/9/python-and-pola/ Discussed on HN too: http://news.ycombinator.com/item?id=2744703 http://news.ycombinator.com/item?id=2744703
- andrewcooke 15y agoone workaround is to make your decorators require keyword arguments (which often makes good sense from a documentation POV). you can then add a first keyword argument as gatekeeper, with default value None, and check whether it has been defined. if so, the decorator was used incorrectly. you can see what i mean here - http://code.google.com/p/lepl/source/browse/src/lepl/matchers/support.py#599 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.
- deleted 15y ago[deleted]
- omaranto 15y agoIt only feels wrong because you think of them as decorators without arguments and decorators with arguments: they really are decorators stored in variables and decorators computed by function calls. :)
- rbonvall 15y agoThat's exactly how I see it. One could have also, for example, lists of decorators, @a[1] def f(x): ...
- omaranto 15y agoIt only feels wrong because you think of them as decorators without arguments and decorators with arguments: they really are decorators stored in variables and decorators computed by function calls. :)
- SoftwareMaven 15y agoI do. The people who don't are thinking from the implementor perspective instead of the user perspective. 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.