On Tue, Jul 20, 2010 at 11:48 PM, Antoine Pitrou firstname.lastname@example.org wrote:
On Wed, 21 Jul 2010 00:28:03 +0200 Antoine Pitrou email@example.com wrote:
I am worried that this complexifies Python syntax without any obvious benefit in terms of expressive power, new abstractions, or concision. There is a benefit (learning curve, readibility of foreign code) to a simple syntax.
I'll add another issue:
- currently, lexical blocks (indentation following a colon) are used
for control flow statements; this proposal blurs the line and makes visual inspection less reliable
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.).
I also disagree with the rationale which states that the motivation is similar to that for decorators or list comprehensions. Decorators and list comprehensions add value by making certain constructs more concise and more readable (by allowing to express the construct at a higher level through the use of detail-hiding syntax); as for decorators, they also eliminate the need for repeating oneself. Both have the double benefit of allowing shorter and higher-level code.
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. The 'given' block has a similar effect of changing the order in which the (human) reader encounters things: it lets you see the important part first, e.g.
c = sqrt(a*a + b*b)
and put the definitions for a and b off till later. This can both help the author "stay in the flow" and emphasize the most important parts for the reader, similar to top-down programming using forward references between functions or methods.
I personally use top-down just about evenly with bottom-up (though in different circumstances), and I think it would be useful to have more support for top-down coding at the statement level. That's why ABC had refinements, too. I dropped them from Python because I had to cut down the design as much as possible to make it possible to implement in a reasonable time as a skunkworks project. But I always did like them in ABC.
Whether this is enough to compensate for the larger grammar is an open question.
The "given" syntax (I don't know how to call it: statement? postfix? appendage?), however, brings none of these benefits: it is almost pure syntactic sugar, and one which doesn't bring any lexical compression since it actually increases code size, rather than decrease it.
But it decreases exposure by limiting the scope of the variables defined in the 'given' block, just like generator expressions and (in Python 3) list comprehensions do. In larger functions it is easy to accidentally reuse variables and this occasionally introduces bugs (the most common case probably being the loop control variable for a small (often inner) loop overwriting a variable that is set far above the loop in the same scope but is used far below it).