Understanding Python Decorators

http://stackoverflow.com/questions/739654/understanding-python-decorators/1594484#1594484

by hiwaylon • 15 years ago

126 24 15 years ago

yason• 15 years ago

I must say that for such a simple concept as decorator, this answer surely used up all the wireframe there ever was allocated for making examples.

sebkomianos• 15 years ago

I am pretty sure the Python community is always up for better explanations!

DasIch• 15 years ago

Better explanations?

   @foo
   def bar():
       ...

Is syntax sugar for

   def bar():
       ...
   bar = foo(bar)

That is all there is to it. It's just syntax sugar to make this particular design pattern more convenient to use.

These explanations add more confusion then they dissolve and give off the impression that this is some kind of expert python foo which is clearly isn't.

mykhal• 15 years ago

less is more

peteretep• 15 years ago

Step 1: Huh, that's a pretty cool feature

Step 2: I bet I could ...

Step 3: Quick check of CPAN

Step 4: Zounds. http://search.cpan.org/~erwan/Python-Decorator-0.03/lib/Pyth...

grncdr• 15 years ago

That's pretty cool. I wonder if I could get away with using this at $work...

Not to mention, one could alter the implementation to remove the inconsistency people are complaining about in Python.

buckwild• 15 years ago

I use decorators all of the time. However, I still learned something while reading this comprehensive explanation. Totally worth adding to my bookmarks.

jackowayed2• 15 years 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• 15 years ago

In your own code you can just wrap argument-less decorators in a function.

    def decorator():
      return some_library.decorator_with_no_args

    @decorator()

jackowayed2• 15 years ago

But 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• 15 years ago

Armin 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/

Discussed on HN too:

http://news.ycombinator.com/item?id=2744703

andrewcooke• 15 years ago

one 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/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.

omaranto• 15 years ago

It 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• 15 years ago

That's exactly how I see it. One could have also, for example, lists of decorators,

    @a[1]
    def f(x):
        ...

SoftwareMaven2• 15 years ago

I 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.

kingkilr2• 15 years ago

Not sure where he gets that Python ships a memoize decorator.

ddbeck• 15 years ago

While not actually called memoize, Python 3.2 ships with the lru_cache decorator in the standard library module functools.

http://docs.python.org/dev/library/functools.html#functools....

kingkilr2• 15 years ago

I'm aware, there was also almost an LFU cache decorator in there.

awegawef• 15 years ago

A very good response, glad to see it on SO. It's also worth mentioning that decorators can be classes.

salem• 15 years ago

Python decorators are extremely useful, especially for neatly adding caching. Style aside, it's extremely cool to be able to add LRU caching, or memcached for a function with one line of code.

krosaen• 15 years ago

a nice use case for web apps: making sure the current user is logged in, and / or has permission to access a specific resource. removes a ton of boilerplate for redirecting to the login page or returning a 403. tornado makes use of this with the authenticated decorator.

SoftwareMaven2• 15 years ago

His answer to metaclasses is worth a read, too: http://stackoverflow.com/questions/100003/what-is-a-metaclas...

Understanding Python Decorators

Related Stories