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.