[Python-ideas] Fwd: Re: @return?

[Conrad Irwin]

On 04/16/2010 03:52 AM, alex23 wrote:
> Conrad Irwin <conrad.ir... at 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