Named loops for breaking

[James Harris]

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.
>
> > 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/2007-July/
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