[Python-ideas] for/except/else

[Wolfgang Maier]

On 03/02/2017 07:05 PM, Brett Cannon wrote:
>
>     - overall I looked at 114 code blocks that contain one or more breaks
>
>
> I wanted to say thanks for taking the time to go through the stdlib and
> doing such a thorough analysis of the impact of your suggestion! It
> always helps to have real-world numbers to know whether an idea will be
> useful (or not).
>
>
>
>     - 84 of these are trivial use cases that simply break out of a while
>     True block or terminate a while/for loop prematurely (no use for any
>     follow-up clause there)
>
>     - 8 more are causing a side-effect before a single break, and it would
>     be pointless to put this into an except break clause
>
>     - 3 more cause different, non-redundant side-effects before different
>     breaks from the same loop and, obviously, an except break clause would
>     not help them either
>
>     => So the vast majority of breaks does *not* need an except break *nor*
>     an else clause, but that's just as expected.
>
>
>     Of the remaining 19 non-trivial cases
>
>     - 9 are variations of your classical search idiom above, i.e., there's
>     an else clause there and nothing more is needed
>
>     - 6 are variations of your "nested side-effects" form presented above
>     with debatable (see above) benefit from except break
>
>     - 2 do not use an else clause currently, but have multiple breaks that
>     do partly redundant things that could be combined in a single except
>     break clause
>
>     - 1 is an example of breaking out of two loops; from
>     sre_parse._parse_sub:
>

[...]

>     - finally, 1 is a complicated break dance to achieve sth that clearly
>     would have been easier with except break; from typing.py:
>
>     My summary: I do see use-cases for the except break clause, but,
>     admittedly, they are relatively rare and may be not worth the hassle of
>     introducing new syntax.
>
>
> IOW out of 114 cases, 4 may benefit from an 'except' block? If I'm
> reading those numbers correctly then ~3.5% of cases would benefit which
> isn't high enough to add the syntax and related complexity IMO.

Hmm, I'm not sure how much sense it makes to express this in percent 
since the total your comparing to is rather arbitrary.
The 114 cases include *any* for/while loop I could find that contains at 
least a single break. More than 90 of these loops do not use an "else" 
clause either showing that even this currently supported syntax is used 
rarely.
I found only 19 cases that are complex enough to be candidates for an 
except clause (17 of these use the else clause). For 9 of these 19 (the 
ones using the classical search idiom) an except clause would not be 
applicable, but it could be used in the 10 remaining cases (though all 
of them could also make use of a flag or could be refactored instead). 
So depending on what you want to emphasize you could also say that the 
proposal could affect as much as 10/19 or 52.6% of cases.