> If you don't have an education in functional programming, a closure definition is quite a lot to dump on folk. That's true, I agree. It's not good when you h

> If you don't have an education in functional programming, a closure definition is quite a lot to dump on folk. That's true, I agree. It's not good when you have to explain a piece of code to every single developer (or even a majority of them) that comes to the project. It would be different in Ruby or JS, but Python developers tend to be more procedural and OO oriented, with FP being less widely known and used. > All abstractions are a trade-off between "how easy is it for the writer " vs "how easy is it for the reader." Yes, definitely. If you can solve a problem with simpler tools, you should do that. If you can solve a problem in a way that's easier to follow, you should do that, even at the cost of some repetition. All abstractions leak, and if you can solve a problem without introducing yet another leaky abstraction - you should do that. On the other hand, if your abstraction is tight enough not to leak too much, you can often get away with it by simply documenting how to use it. Huge masses of Python programmers use Django ORM, for example, without ever caring about the metaclasses and descriptors that make them work. Many of the more junior devs don't even understand that the ORM is basically a builder for SQL queries. It's not ideal and they sometimes introduce problems to the codebase by doing N+1 queries where 1 query would suffice (for example) and they become lost at the first sight of `QuerySet.raw` method. Until they hit one of these, though, they can still add value to the project. > Decorators have a "hurdle" rate of complexity for the writer, and need a sufficient number of readers to justify. Agreed. The complexity of creating a closure that wraps a given function to add a useful logic to it is definitely higher than simpler solutions, like template method (for example). And while using a decorator has little syntactic overhead, there's a cognitive overhead should the new developer need to change the decorator's logic. In other words: simple is best. No argument here :)