Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Understanding Python Decorators

stackoverflow.com

Post reply on HN
Print view View original

21–28 of 28 posts

Re: Understanding Python Decorators

#21

Post by omaranto »

jackowayed wrote: post #11

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 i…

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. :)

Re: Understanding Python Decorators

#22

Post by omaranto »

jackowayed wrote: post #11

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 i…

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. :)

Re: Understanding Python Decorators

#23

Post by grncdr »

peteretep wrote: post #9

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

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.

Re: Understanding Python Decorators

#24

Post by salem »

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.

Re: Understanding Python Decorators

#25

Post by krosaen »

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.

Re: Understanding Python Decorators

#26

Post by rbonvall »

omaranto wrote: post #21
jackowayed wrote: post #11

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 i…

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. :)

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

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

Re: Understanding Python Decorators

#27

Post by SoftwareMaven »

jackowayed wrote: post #11

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 i…

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.

Post reply on HN