[Python-ideas] 'where' statement in Python?

Terry Reedy tjreedy at udel.edu
Thu Jul 22 04:04:02 CEST 2010


On 7/20/2010 7:08 PM, Guido van Rossum wrote:

> I see a similar possibility as for decorators, actually. A decorator
> is very simple syntactic sugar too, but it allows one to emphasize the
> decoration by putting it up front rather than hiding it after the
> (possibly very long) function.

Because you chose to put multiple decorators in 'nested' order, I can 
consistently read decorated definitions as multi-statement'expressions' 
like so:

@f1(arg) #(
@f2 # (
def f(): pass
# ))

with the function name propagated out. Reading expression inside out is 
nothing new. (The opposite decorator order would have made this 'trick' 
impossible and decorators harder for me to read.) I do not particularly 
see this syntax as 'emphasizing' the decoration any more than 
f(g(2*x+y**z) 'emphasizes' f or g over the operator expression.

[changing the order]
 > This is indeed a bit of a downside; if you see
 >
 >    blah blah blah:
 >        x = blah
 >        y = blah
 >
 > you will have to look more carefully at the end of the first blah blah
 > blah line to know whether the indented block is executed first or
 > last. For all other intended blocks, the *beginning* of the indented
 > block is your clue (class, def, if, try, etc.).

Yes! This is a great feature of Python. For decorators, the *initial* 
'@' is the clue to shift reading mode. If givens were accepted, I would 
strongly prefer there to be a similar initial clue.

On function definition order: I generally prefer to write and read 
definitions before they are used. (Mathematicians usually present and 
prove lemmas before a main theorem.) The major exception is the __init__ 
method of a class, which really is special as it defines instance 
attributes. I can imagine a module with one main and several helper 
functions starting with the main function, but there should first be a 
doc string listing everything with at least a short phrase of explanation.

-- 
Terry Jan Reedy




More information about the Python-ideas mailing list