Named loops for breaking

bartc bartc at freeuk.com
Thu Mar 11 12:22:49 EST 2010


James Harris wrote:
> On 10 Mar, 06:29, "Gabriel Genellina" <gagsl-... at yahoo.com.ar> wrote:
>> En Tue, 09 Mar 2010 18:41:10 -0300, Daniel Klein <bri... at gmail.com>
>> escribi :
>>
>>> Basically I'm wondering if there are any plans to implemented named
>>> loops in Python, so I can tell a break command to break out of a
>>> specific loop in the case of nested loops.
>>
>> See PEP3136 [1] and its rejection note [2]
>> I think you may find some more discussion in the python-ideas list.

> Breaking out of an inner loop is just as natural as breaking out of
> the immediately enclosing loop. ISTM that if one is allowed the other
> should be also.

Exactly. Python already has single-level break (probably some baggage 
carried over from C), and some of the same arguments can be applied to that 
too.

Given that break does exist, it's annoying that in the followed contrived 
example:

def f(n):
        return n==2

for i in range(10):
        print i
        if f(0): break
        if f(1): break
        if f(2): break
        if f(3): break

I can't turn the list of ifs into a loop. I can use break embedded inside a 
statement inside a loop, provided it's not another loop! That's 
discrimination...

> There are often times when it *is* better to factor out the code to a
> different function but adding a function just to enable a break from
> an inner loop doesn't seem to me a good reason.

Multi-level breaks should just have been part of the language, so they are 
available to those who want them, and ignored by everyone else.

(And in languages where I've implemented them -- all generally faster than 
Python -- they have no impact on performance. I also had 4 loop controls 
rather than just 2, all multi-level, and the world hasn't ended yet.)

My experience of these break statements is that they are used infrequently 
in final code. But they are handy when developing code too: you don't want 
to waste time refactoring, and generally turning code upside-down, when the 
code has to be rewritten a dozen times anyway.

-- 
Bartc 




More information about the Python-list mailing list