[Python-ideas] Moving return above statements [was Re: Syntax for defining parametric decorators]

[Stephen J. Turnbull]

Nick Coghlan writes:
 > On Thu, Jul 12, 2012 at 11:37 AM, Steven D'Aprano <steve at pearwood.info> wrote:
 > > Looking back at "in return", here's a simple example which doesn't use
 > > nested functions. Compare:
 > >
 > >
 > > def function(arg):
 > >     in return value
 > >     value = process(arg)
 > >     print("Value is", value)
 > 
 > Like a decorator line, the "in" clause is effectively part of the
 > subsequent function/class definition - it's not a separate statement.
 > That's why there's no ending colon. However, I'm now thinking a
 > leading @ might be appropriate in order to make the decorator parallel
 > crystal clear.

Indeed I would prefer the leading "@", because the in clause
(syntactically) "decorates" the following definition.

But isn't Steven's example just plain invalid on two counts?  That is,
in the PEP (1) the "in" modifies a function or class definition, not
an arbitrary statement, and (2) it does not have suite scope, it has
statement scope.  Another way of expressing (2) is that the print
statement above is dead code.

With respect to the idea itself, I'm a little concerned that in the
case of the decorator, the idea is to deemphasize the decoration in
favor of focusing on the decorated definition, while in the case of
the "in" clause, the idea is to deemphasize the definition in favor of
focusing on the "decorating" statement.

Perhaps in practice this won't be a problem, though.  For the "in"
clause, the order of presentation will provide the emphasis on the
"decorating" statement.  OTOH, for the decorators, the order of
presentation is no big deal compared to the avoidance of DRY
violation.