Jeff Bone writes: > IMHO, making decorators functions is a bad idea. Decorators are > metadata about the function to which they refer. Bob Ippolito responds: > Uh, the WHOLE POINT we want this is to have side-effects. If it > doesn't make the function act in a different way, it might as well live > in the doc string or something. > > The most wanted use cases are all function transformations, not the > setting attributes on function objects. And back to Jeff: > Declarative vs. imperative. Design-time *definitional* modification of > behavior vs. runtime. I don't really think you want side-effects in > the literal sense. E.g. "classmethod" isn't a side-effect, it's a > definitional thing. If you really want side-effecting operations on > functions, you've already got that given higher-order / first-class > functions. Just one more opinion here, but I'm with Bob on this one. Sure, many of the uses I envision are "declarative" in the sense that they just associate metadata with the function. But many other uses I envision would alter the function's behavior. Yes, of COURSE it can all be achieved by applying higher-order operations to Python's first-class functions -- in my mind, that's what decorators ARE... a cleaner syntax allowing easier use of higher order functions. -- Michael Chermside This email may contain confidential or privileged information. If you believe you have received the message in error, please notify the sender and delete the message without copying or disclosing it.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4