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

[Guido van Rossum]

On Tue, Jul 20, 2010 at 11:48 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Wed, 21 Jul 2010 00:28:03 +0200
> Antoine Pitrou <solipsis at pitrou.net> 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).

-- 
--Guido van Rossum (python.org/~guido)