[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.python

Named loops for breaking

Daniel Klein

3/9/2010 9:41:00 PM

Hey,

I did a little searching and couldn't really find much recent on this.
The only thing I found was this:

http://groups.google.com/group/comp.lang.python/browse_thread/thread/a696624c92b91181/5b7479fdc3362b83?lnk=gst&q=break+named+loop#5b7479...

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. Currently I'm using boolean
flag variables, but I find that very clumsy. I know this idea of
breaking out of specific loops from javascript; I guess java does it
too. It just seems a very Pythonian idea to me: clear, promotes code
legibility, seems obvious.
8 Answers

Paul Rubin

3/9/2010 9:58:00 PM

0

Daniel Klein <bringa@gmail.com> writes:
> 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. Currently I'm using boolean
> flag variables, but I find that very clumsy.

The usual way to do this in Python is with an exception, perhaps a
specially named one if that makes your code clearer:

class Whatever(Exception): pass
...
try:
for x in thingie:
for y in x.whatsis():
if lose(y): raise Whatever
...
except Whatever: pass

This situation doesn't come up all that often and you should
probably ask yourself if you really need those nested loops.

You might also be able to put the nested loop structure into a
function that you can then exit with a return statement.

alex23

3/10/2010 2:10:00 AM

0

Daniel Klein <bri...@gmail.com> wrote:
> 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.

You should be able to do this with the goto module: http://entrian...

But please note that I'm not seriously advocating its use :)

Gabriel Genellina

3/10/2010 6:29:00 AM

0

En Tue, 09 Mar 2010 18:41:10 -0300, Daniel Klein <bringa@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.

> Currently I'm using boolean
> flag variables, but I find that very clumsy. I know this idea of
> breaking out of specific loops from javascript; I guess java does it
> too. It just seems a very Pythonian idea to me: clear, promotes code
> legibility, seems obvious.

Although I've occasionally missed the feature myself, I agree with Guido's
arguments against it. You have several alternatives: refactor the loop
into an auxiliary function, use a specific exception, add boolean flags,
or repeat the test at the outer levels. (I usually choose the first).

[1] http://www.python.org/dev/peps...
[2] http://mail.python.org/pipermail/python-3000/2007-July/0...

--
Gabriel Genellina

Jean-Michel Pichavant

3/10/2010 1:23:00 PM

0

Daniel Klein wrote:
> Hey,
>
> I did a little searching and couldn't really find much recent on this.
> The only thing I found was this:
>
> http://groups.google.com/group/comp.lang.python/browse_thread/thread/a696624c92b91181/5b7479fdc3362b83?lnk=gst&q=break+named+loop#5b7479...
>
> 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. Currently I'm using boolean
> flag variables, but I find that very clumsy. I know this idea of
> breaking out of specific loops from javascript; I guess java does it
> too. It just seems a very Pythonian idea to me: clear, promotes code
> legibility, seems obvious.
>
Strange that I've rarely been in need of such feature. Continues &
breaks are mess-prone, adding an 'outter block' break feature would just
increase the messing potential of such controls.
Just my opinion though.

Still there's a control that is able to break outter scopes : return.
So embed your loop in a function and you'll be able to break whenever
you want.

JM

Daniel Klein

3/10/2010 3:16:00 PM

0

Thanks for the link to the PEP. I should search through PEPs first
next time :)

Okay, I understand Guido's reasoning and yield the point. I typed up
the specific example in which I came across this problem and, while
doing so, realized there's a much better way of approaching the
problem, so thank you for that as well :)

James Harris

3/10/2010 9:54:00 PM

0

On 10 Mar, 06:29, "Gabriel Genellina" <gagsl-...@yahoo.com.ar> wrote:
> En Tue, 09 Mar 2010 18:41:10 -0300, Daniel Klein <bri...@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.
>
> > Currently I'm using boolean
> > flag variables, but I find that very clumsy. I know this idea of
> > breaking out of specific loops from javascript; I guess java does it
> > too. It just seems a very Pythonian idea to me: clear, promotes code
> > legibility, seems obvious.
>
> Although I've occasionally missed the feature myself, I agree with Guido's  
> arguments against it.

I don't agree with Guido's second reason in particular. He writes in
the link Gabriel provided

> [2]http://mail.python.org/pipermail/python-3000/...
008663.html

G> However, I'm rejecting it on the basis that code so complicated to
G> require this feature is very rare. In most cases there are existing
G> work-arounds that produce clean code, for example using 'return'.
G> While I'm sure there are some (rare) real cases where clarity of
the
G> code would suffer from a refactoring that makes it possible to use
G> return, this is offset by two issues:

G> 1. The complexity added to the language, permanently. This affects
not
G> only all Python implementations, but also every source analysis
tool,
G> plus of course all documentation for the language.

Guido may have a point here about source tools but I don't think the
language becomes more complex. If anything it would become more
orthogonal - i.e. fewer arbitrary restrictions. And documentation is
needed for any change so saying that documentation would need to be
updated is an odd reason to reject a change.

G> 2. My expectation that the feature will be abused more than it will
be
G> used right, leading to a net decrease in code clarity (measured
across
G> all Python code written henceforth). Lazy programmers are
everywhere,
G> and before you know it you have an incredible mess on your hands of
G> unintelligible code.

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.

> You have several alternatives: refactor the loop  
> into an auxiliary function, use a specific exception, add boolean flags,  
> or repeat the test at the outer levels. (I usually choose the first).

The auxiliary function idea (Guido's preference as well as Gabriel's)
works but it may require accessing of variables which don't appear in
the function interface, and the "return" in that function is no
different from the break dropping through multiple levels. Return does
exactly that (as well as setting a result value).

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.

James

Alf P. Steinbach

3/10/2010 10:53:00 PM

0

* James Harris:
> On 10 Mar, 06:29, "Gabriel Genellina" <gagsl-...@yahoo.com.ar> wrote:
>> En Tue, 09 Mar 2010 18:41:10 -0300, Daniel Klein <bri...@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.
>>
>>> Currently I'm using boolean
>>> flag variables, but I find that very clumsy. I know this idea of
>>> breaking out of specific loops from javascript; I guess java does it
>>> too. It just seems a very Pythonian idea to me: clear, promotes code
>>> legibility, seems obvious.
>> Although I've occasionally missed the feature myself, I agree with Guido's
>> arguments against it.
>
> I don't agree with Guido's second reason in particular. He writes in
> the link Gabriel provided
>
> > [2]http://mail.python.org/pipermail/python-3000/...
> 008663.html
>
> G> However, I'm rejecting it on the basis that code so complicated to
> G> require this feature is very rare. In most cases there are existing
> G> work-arounds that produce clean code, for example using 'return'.
> G> While I'm sure there are some (rare) real cases where clarity of
> the
> G> code would suffer from a refactoring that makes it possible to use
> G> return, this is offset by two issues:
>
> G> 1. The complexity added to the language, permanently. This affects
> not
> G> only all Python implementations, but also every source analysis
> tool,
> G> plus of course all documentation for the language.
>
> Guido may have a point here about source tools but I don't think the
> language becomes more complex. If anything it would become more
> orthogonal - i.e. fewer arbitrary restrictions. And documentation is
> needed for any change so saying that documentation would need to be
> updated is an odd reason to reject a change.
>
> G> 2. My expectation that the feature will be abused more than it will
> be
> G> used right, leading to a net decrease in code clarity (measured
> across
> G> all Python code written henceforth). Lazy programmers are
> everywhere,
> G> and before you know it you have an incredible mess on your hands of
> G> unintelligible code.
>
> 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.
>
>> You have several alternatives: refactor the loop
>> into an auxiliary function, use a specific exception, add boolean flags,
>> or repeat the test at the outer levels. (I usually choose the first).
>
> The auxiliary function idea (Guido's preference as well as Gabriel's)
> works but it may require accessing of variables which don't appear in
> the function interface, and the "return" in that function is no
> different from the break dropping through multiple levels. Return does
> exactly that (as well as setting a result value).
>
> 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.

Gabriel Genellina mentioned these alternatives: "refactor the loop into an
auxiliary function, use a specific exception, add boolean flags, or repeat the
test at the outer levels. (I usually choose the first)"

And I agree, but in Python there is at least one more very practical
alternative, namely /flatting/ the nested loops, representing them as a single loop.

It can go like this -- very artifical construed example:


<code>
from __future__ import print_function
try:
range = xrange
except:
pass

def inclusive_range( first, last ):
return range( first, last + 1 )

def xy_range( x_range, y_range ):
for x in x_range:
for y in y_range:
yield (x, y)

def main():
needle = 42
x_range = inclusive_range( 1, 10 )
y_range = inclusive_range( 1, 10 )
pos = None
for (x, y) in xy_range( x_range, y_range ):
if x*y == needle:
pos = (x, y)
break
if pos is None:
print( "Sorry, {0} not found.".format( needle ) )
else:
print( "{0} found at {1}.".format( needle, pos ) )

main()
</code>


Cheers & hth.,

- Alf

PS: Gabriel, if you read this and don't understand it (as you mentioned in
another thread that you never understand my postings), please just ask!

Bartc

3/11/2010 5:23:00 PM

0

James Harris wrote:
> On 10 Mar, 06:29, "Gabriel Genellina" <gagsl-...@yahoo.com.ar> wrote:
>> En Tue, 09 Mar 2010 18:41:10 -0300, Daniel Klein <bri...@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