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/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 -- http://mail.python.org/mailman/listinfo/python-list
