On 04/16/2010 03:52 AM, alex23 wrote:

Conrad Irwin <conrad.ir...@googlemail.com> wrote:

...

result = register_callback(def success(arg): print(arg) )

I think it is significantly nicer than the decorator abuse:

@register_callback def result(arg): print(arg)

How is that an abuse of the decorator syntax?

Well, It would be clearer expanded as: def success(arg): print(arg) result = register_callback(success) But in order to assign the result to "result", I renamed the function, register_callback returns an int.

How is your @return syntax more clear in its intent than:

from decorator import decorator

@decorator def a_decorator(...): ....

@decorator solves one common case extremely well, though perusing its documentation I notice lots of "@return" use still - in any decorator that takes parameters before the function (arguably this could be solved by modifying "@decorator"). I also feel that, in the memoize example, the author has gone out of his way to use @decorator where creating an enclosing scope and "@return"ing would be less intrusive.

Is returning a function from within another function - outside of decorators - that recurring a task that we need new syntax that not only overloads existing syntax for a different use, but also disrupts the readability of a function?

In light of the above, yes, there are enough uses for it, and the feeling of cleanliness it provides. Using it with classes is also useful (found in django) - though much rarer: def infix(bp, func): class Operator(TokenBase): ... def led(self, left, parser): ... def eval(self, context): ... return Operator The syntax overloading was intentional, "@return" is very like a decorator in behaviour (albeit not in implementation). Introducing a new syntax to do something so similar seems very heavy-handed. Having @return next to the definition emphasizes that flow of control, and (particularly for lengthy definitions) doesn't leave an orphaned return statement floating somewhere at the end. def infix(bp, func): @return class Operator(TokenBase): ... def led(self, left, parser): ... def eval(self, context): ... Obviously, on matters of aesthetics, anyone can be right. I am, however, convinced that avoiding repetition (even if it is just of a name) in an unambiguous manner is a worthy goal. Conrad