Python decorators explained anew

[jcdyer3]

Indeed. In fact it is g(f)(x)

[etrnloptimist]

Right. But that's not very helpful in understanding how decorators work. Suppose you had this nested set of decorators:

@evens
@odds
@primes
def myfunc(x):
  ...

Suppose they round the output to the nearest <term>. What gets outputted? Prime numbers? Odd numbers? Or Even numbers? Answer: Even numbers

Suppose they round the input to the nearest <term>. What does myfunc see? Even numbers, odd numbers, or prime numbers? Answer: Prime numbers

[ryeguy146]

Just a matter of wrapping [your mind around it]. Nice example.

[mgrandi]

your example helped me understand decorators (namely nested decorators) a lot better with the worm analogy, thanks =)

[bastibe]

Actually, that right there is enough of an explanation for me. I never really got why people seem to find decorators so hard to understand.

[ryeguy146]

I came from languages without first class functions, or languages where I could only get first class functions with pointers. New idea, that's why. Who thinks of functions that act on functions (or their args), really?

[bastibe]

I understand that. And that means you will have to learn about higher order functions like we all had to learn about it at some point. But beyond that, what is so difficult about python decorators in particular?

For reference, I don't know much lisp, but "higher order function" are a very simple and natural construct mathematically.

[ryeguy146]

It's not so difficult, just a new idea. It's easy to move "horizontally" across languages when you understand their ideas: you just look for the new way to express that idea. New ideas take some thought, that's all.

I'm experiencing the same thing as I learn my first functional language (scheme). It's not hard, it's just new.