3 ms·

> Python decorators are “magic” until you make a few of your own. To add to this, you must try things to understand them not only so you can wield them, but so

> Python decorators are “magic” until you make a few of your own. To add to this, you must try things to understand them not only so you can wield them, but so you know what not to do. Decorators are squarely in that latter category for me. Things that feel magical, expressivity, structure, data model, abstractions... there is an element of experience required to develop a robust understanding of not only the power but the costs, which are often subtle and pernicious.

nxpnsv 4y ago
I want examples of terrible decorators now…
- lordgrenville 4y ago
  https://news.ycombinator.com/item?id=16084238 https://news.ycombinator.com/item?id=16084238
  - nxpnsv 4y ago
    Excellent, thanks!
urthor 4y ago
I, really, really, disagree with decorators not being worthwhile Decorators are a very "high" level of abstraction. Leave aside dependency injection, clojures and currying and all that jazz which worms its way in here. Decorators are, actually, really excellent for libraries, used by a ton of people. They're exceptionally easy for end users to use. Cost is that the designer has to #1 deal with fancy programming. #2 The designer has to really understand all the user cases of what they're decorating. But: 1. You're good enough to do fancy programming. 2. You're writing software that's popular with a lot of people. Then decorators are really convenient for the people using them. Right tool, right job.
- xyzzy_plugh 4y ago
  > Decorators are a very "high" level of abstraction. Leave aside dependency injection, clojures and currying and all that jazz which worms its way in here. I don't follow. They're magic. Magic (and fancy programming) is generally bad in a professional, software engineering environment. If you're writing software for you, do whatever you want. But I'd you're writing software for your peers, dependency injection, closures and currying (and all that jazz) are significantly more literate and easier to follow. Decorators nearly universally have hidden side effects through hidden state.
  - klibertp 4y ago
    Hidden state is not bad. That's the entire premise of Object Oriented programming: we hide the state with encapsulation and only expose methods that act on that hidden state. Closures are exactly equivalent to objects. (Makes sense, given how JS uses closures to implement objects and how Java uses classes to implement lambdas...) What's bad is global state, but in Python specifically - and in any language supporting modules and/or being class-only like Java - the globals are actually confined to their own Singleton instances (ie. the modules or static members of classes). Hiding state in a closure is exactly equivalent to hiding the state in private fields on an object. It's not magic. It's just an alternative formulation of the same idea. In Python, it's slightly less convenient to use due to some peculiarities around scopes, but it's a valid technique nevertheless. You seem to agree, saying that "closures and currying [...] are significantly more literate and easier to follow". But then, I don't understand what is your problem with decorators. They're just a convenient syntax for higher-order functions, that often happen to be also closures. You said they are easy to follow; the same should be true for decorators, then. Dependency injection, included in your list of easy to follow things, is often implemented with decorators in Python. Basically, decorators are just a special syntax for the following pattern: def f(): pass f = some_higher_order_function(f) and nothing more. How complex or "magical" you'd like your `some_higher_order_function`s to be is your choice, but that has literally nothing to do with decorators syntax... I would agree if you singled out descriptors, metaclasses, or stack manipulation, but things like decorators or context managers are simple enough to be your everyday tool for writing Python code.

nxpnsv 4y ago

I want examples of terrible decorators now…

lordgrenville 4y ago
https://news.ycombinator.com/item?id=16084238 https://news.ycombinator.com/item?id=16084238
- nxpnsv 4y ago
  Excellent, thanks!

urthor 4y ago

I, really, really, disagree with decorators not being worthwhile Decorators are a very "high" level of abstraction. Leave aside dependency injection, clojures and currying and all that jazz which worms its way in here. Decorators are, actually, really excellent for libraries, used by a ton of people. They're exceptionally easy for end users to use. Cost is that the designer has to #1 deal with fancy programming. #2 The designer has to really understand all the user cases of what they're decorating. But: 1. You're good enough to do fancy programming. 2. You're writing software that's popular with a lot of people. Then decorators are really convenient for the people using them. Right tool, right job.

xyzzy_plugh 4y ago
> Decorators are a very "high" level of abstraction. Leave aside dependency injection, clojures and currying and all that jazz which worms its way in here. I don't follow. They're magic. Magic (and fancy programming) is generally bad in a professional, software engineering environment. If you're writing software for you, do whatever you want. But I'd you're writing software for your peers, dependency injection, closures and currying (and all that jazz) are significantly more literate and easier to follow. Decorators nearly universally have hidden side effects through hidden state.
- klibertp 4y ago
  Hidden state is not bad. That's the entire premise of Object Oriented programming: we hide the state with encapsulation and only expose methods that act on that hidden state. Closures are exactly equivalent to objects. (Makes sense, given how JS uses closures to implement objects and how Java uses classes to implement lambdas...) What's bad is global state, but in Python specifically - and in any language supporting modules and/or being class-only like Java - the globals are actually confined to their own Singleton instances (ie. the modules or static members of classes). Hiding state in a closure is exactly equivalent to hiding the state in private fields on an object. It's not magic. It's just an alternative formulation of the same idea. In Python, it's slightly less convenient to use due to some peculiarities around scopes, but it's a valid technique nevertheless. You seem to agree, saying that "closures and currying [...] are significantly more literate and easier to follow". But then, I don't understand what is your problem with decorators. They're just a convenient syntax for higher-order functions, that often happen to be also closures. You said they are easy to follow; the same should be true for decorators, then. Dependency injection, included in your list of easy to follow things, is often implemented with decorators in Python. Basically, decorators are just a special syntax for the following pattern: def f(): pass f = some_higher_order_function(f) and nothing more. How complex or "magical" you'd like your `some_higher_order_function`s to be is your choice, but that has literally nothing to do with decorators syntax... I would agree if you singled out descriptors, metaclasses, or stack manipulation, but things like decorators or context managers are simple enough to be your everyday tool for writing Python code.