5 ms·

Agreed that they can be tricky initially and hard to debug, but I think they're totally worth it for eliminating repetitive code. And IMO as long as there isn'

by dcosson 15y ago

Agreed that they can be tricky initially and hard to debug, but I think they're totally worth it for eliminating repetitive code. And IMO as long as there isn't a bug in the decorator itself, code with decorators can be just as readable (if not more so) to someone else (e.g. decorating your functions with @authenticated instead of if self.user.is_authenticated: # blah, blah blah)

craigyk 15y ago
if Python had better function syntax and anonynous functions, decorators wouldn't even be a 'thing'
- j-kidd 15y ago
  Can you elaborate on that? The more I use Python, the more I find it to be a well thought out language with a very consistent feel, allowing me to write code without thinking. Well, except when it comes to decorators. How would you propose to improve the syntax?
- irahul 15y ago
  > if Python had better function syntax and anonynous functions, decorators wouldn't even be a 'thing' Better function syntax? What's wrong with python's function syntax and how does it relate to decorators? Python does have anonymous functions, though they are limited: You can have only 1 expression, you can't have statements, and you can't have local variables. The reasoning is lambdas should be used for small operations; for everything else, named functions should be used. The reasoning behind lambdas is arguable, but it still doesn't explain how it affects decorators. Consider: def memoize(fn): from functools import wraps @wraps(fn) def memoized_fn(*args): if not memoized_fn.cache.has_key(args): memoized_fn.cache[args] = fn(*args) return memoized_fn.cache[args] memoized_fn.cache = {} return memoized_fn @memoize def fib(n): if n < 2: return n return fib(n-1) + fib(n-2) print fib(100) What would a better function syntax and anonymous functions do so that memoize decorator won't be a thing?
  - maxerickson 15y ago
    Less restricted anonymous functions would allow stuff like this: fib=memoize(function...) So the @ shortcut for: def fib(): ... fib=memoize(fib) wouldn't be necessary to 'clean up' the decoration of the function.
    - irahul 15y ago
      Even if it were possible, I would stick with @memoize def fib: pass fib = memoize(function ...) has unnecessary nesting, and @memoize is cleaner IMO. I am curious - do you find @memoize confusing? Personally for me and anyone I have talked to, @memoize is vanilla - the confusing part is the decorator itself, especially one that takes arguments; that coupled with the fact that classes(which override __call__) and functions are both used as decorators.
      - maxerickson 15y ago
        No, I don't find it confusing. But I read craigyk as mostly talking about the special decorator syntax, not function decoration in general.

by dcosson 15y ago

craigyk 15y ago

if Python had better function syntax and anonynous functions, decorators wouldn't even be a 'thing'

j-kidd 15y ago
Can you elaborate on that? The more I use Python, the more I find it to be a well thought out language with a very consistent feel, allowing me to write code without thinking. Well, except when it comes to decorators. How would you propose to improve the syntax?
irahul 15y ago
> if Python had better function syntax and anonynous functions, decorators wouldn't even be a 'thing' Better function syntax? What's wrong with python's function syntax and how does it relate to decorators? Python does have anonymous functions, though they are limited: You can have only 1 expression, you can't have statements, and you can't have local variables. The reasoning is lambdas should be used for small operations; for everything else, named functions should be used. The reasoning behind lambdas is arguable, but it still doesn't explain how it affects decorators. Consider: def memoize(fn): from functools import wraps @wraps(fn) def memoized_fn(*args): if not memoized_fn.cache.has_key(args): memoized_fn.cache[args] = fn(*args) return memoized_fn.cache[args] memoized_fn.cache = {} return memoized_fn @memoize def fib(n): if n < 2: return n return fib(n-1) + fib(n-2) print fib(100) What would a better function syntax and anonymous functions do so that memoize decorator won't be a thing?
- maxerickson 15y ago
  Less restricted anonymous functions would allow stuff like this: fib=memoize(function...) So the @ shortcut for: def fib(): ... fib=memoize(fib) wouldn't be necessary to 'clean up' the decoration of the function.
  - irahul 15y ago
    Even if it were possible, I would stick with @memoize def fib: pass fib = memoize(function ...) has unnecessary nesting, and @memoize is cleaner IMO. I am curious - do you find @memoize confusing? Personally for me and anyone I have talked to, @memoize is vanilla - the confusing part is the decorator itself, especially one that takes arguments; that coupled with the fact that classes(which override __call__) and functions are both used as decorators.
    - maxerickson 15y ago
      No, I don't find it confusing. But I read craigyk as mostly talking about the special decorator syntax, not function decoration in general.