4 ms·

Well. I have a book that uses a minimal subset of Python as the illustrative language, and oh boy would the examples have been vastly improved if the author had

Well. I have a book that uses a minimal subset of Python as the illustrative language, and oh boy would the examples have been vastly improved if the author had gone the extra yard and added comprehensions into the mix rather than ploddingly building his transformed lists in loops like a Neanderthal. Decorators though I totally agree; had some tooling at work that was gussied up to the point of impenetrability by gratuitous use of decorators. A colleague got so fed up with it he rewrote it in Perl, which was, shockingly, actually a maintainability improvement.

mikepurvis 5y ago
Decorators become pretty hard to reason about as soon as you have to apply more than one of them to the same method. So I think there are cases for them where the ergonomics are fantastic, but exercising restraint is critical— and it's restraint on the part of API/library authors that is needed more than on the part of users, since a lot of the time, it's actually out of users' hands.
- stinos 5y ago
  This. Nothing wrong with decorators per se. Just one typical example: measuring a couple of functions execution time by just decorating them definitely fullfils what the OP wants: simple and readable. Obviously there is more than one way to measure execution time, but the 'there should be one way' mantra really only holds true for very basic things anyway imo. And yes just like any other pattern out there it can be abused. One could try and blame the language for allowing such abuse, but that is not always fair I think, and also not in this case. Bad code is written all the time all over the place, and if a language would try to really really fix that it would be way to restrictive probably and hinder development in other ways. Same story for list comprehensions: it's almost beyond me how one can be against a simple single list comprehension. It's simple, readable, almost beautiful. Now if people start nesting 5 comprehensions it's not so nice anymore; but then is the language to blame (as in, would we really want to forbid nested comprehensions?), or the people?
JoBrad 5y ago
I really love the idea of decorators. However, after having used them in some rather large projects, I have to agree that it contributes to “magic” happening elsewhere in your code that can complicate debugging quite a bit.

mikepurvis 5y ago

Decorators become pretty hard to reason about as soon as you have to apply more than one of them to the same method. So I think there are cases for them where the ergonomics are fantastic, but exercising restraint is critical— and it's restraint on the part of API/library authors that is needed more than on the part of users, since a lot of the time, it's actually out of users' hands.

stinos 5y ago
This. Nothing wrong with decorators per se. Just one typical example: measuring a couple of functions execution time by just decorating them definitely fullfils what the OP wants: simple and readable. Obviously there is more than one way to measure execution time, but the 'there should be one way' mantra really only holds true for very basic things anyway imo. And yes just like any other pattern out there it can be abused. One could try and blame the language for allowing such abuse, but that is not always fair I think, and also not in this case. Bad code is written all the time all over the place, and if a language would try to really really fix that it would be way to restrictive probably and hinder development in other ways. Same story for list comprehensions: it's almost beyond me how one can be against a simple single list comprehension. It's simple, readable, almost beautiful. Now if people start nesting 5 comprehensions it's not so nice anymore; but then is the language to blame (as in, would we really want to forbid nested comprehensions?), or the people?

JoBrad 5y ago

I really love the idea of decorators. However, after having used them in some rather large projects, I have to agree that it contributes to “magic” happening elsewhere in your code that can complicate debugging quite a bit.