[Python-ideas] if expensive_computation() as x:

[Chris Angelico]

On Sat, Feb 15, 2014 at 12:12 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 15 February 2014 10:49, Chris Angelico <rosuav at gmail.com> wrote:
>> And that's my point. No matter how the *computer* sees them, the
>> *programmer* sees them as peers. Adding an additional option to the
>> list should not change the indentation level of any other, because the
>> logical structure of the code hasn't changed.
>
> You snipped the salient point in all this: the relevant case is one
> where the programmer wants to check *different* things, and *only*
> wants to calculate them if the earlier things are false. If they were
> true peers, this approach would work:
>
>     x = alternative_1()
>     y = alternative_2()
>     z = alternative_3()
>
>     if x:
>         # Do something with x
>     elif y:
>         # Do something with y
>     elif z:
>         # Do something with z

I believe they're still peers; they just happen to be unable to fit
into the physical structure of Python that way. Her's a concrete
example: You have a series of regular expressions, and you want to
process whichever one matches. No line of text is allowed to match
more than one regex (to prevent excessive processing), but any line
could match any regex.

if re1.match(line) as match:
    # do stuff with the match object
elif re2.match(line) as match:
    # do different stuff, using the matched substrings
# etc etc etc

Adding another one is as simple as determining its position in the
sequence (since earlier matches take precedence over later ones).
Removing one is just deleting its elif and corresponding block of
code. They are peers. The fact that Python doesn't currently have
syntax that allows this *in an elif chain* doesn't change this; if you
were to write it as pseudo-code, you would write them as peers. That's
why the function-with-return or loop-with-break still looks better,
because it structures the code the way that logically makes sense -
flat, not nested.

ChrisA