3 ms·
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 t
by 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 agoThis. 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?