for...else

Peter Otten __peter__ at web.de
Tue Jun 2 08:27:35 EDT 2015


acdr wrote:

> Hi,
> 
> Currently, in various places in my code, I have the equivalent of:
> 
> for x in it:
>     if complicated_calculation_1():
>         cleanup()
>         break
>     complicated_calculation_2()
>     if complicated_calculation_3():
>         cleanup()
>         break
> 
> Obviously, I'm repeating myself by having two separate calls to
> cleanup(). I can't really see a nicer way to do this. (Though I see
> plenty of non-nice ways to do this, such as adding "broken = True" in
> front of every "break", and then after the loop is done, have an "if
> broken" section.) Other solutions that I'm not particularly fond of
> can be found on stackexchange, where someone else is trying to do the
> same thing:
> http://stackoverflow.com/questions/3296044/opposite-of-python-for-else

Perhaps you like of these:

for x in it:
    if not complicated_calculation_1():
        complicated_calculation_2()
        if not complicated_calculation_3():
            continue
    cleanup()
    break

def f():
    for x in it:
        if complicated_calculation_1():
            break
        complicated_calculation_2()
        if complicated_calculation_3():
            break
    else:
        return
    cleanup()

> I'm wondering if there is a demand for expanding the "for...else"
> functionality to be expanded also have a block of code that only gets
> called if the loop is broken out of. I.e.:
> 
> for x in it:
>     ...
> then:
>     # "break" was called
>     ...
> else:
>     # "break was not called
>     ...

You may not like using a flag, but it's a really obvious approach and the 
situations where it's necessary are not very common. Apart from indentation-
based blocks Python is very middle-of-the-road, so I'd ask if there is an 
existing language that has such a feature, and if yes, is it used 
frequently? I suspect that there are many Python programmers that have never 
even used (for...else).

Python the language is already becoming too complicated for my taste; I 
would rather not add more constructs where there is no significant 
advantage. 





More information about the Python-list mailing list