How to break out of two nested for loops?

[Gareth McCaughan]

Donn Cave wrote:

[I said:]
> | Very true. But for most of us (so I conjecture, anyway) that's
> | a relatively small part of the programming we do. I don't think
> | it's terrible if someone prefers, on stylistic grounds, to use
> | exceptions only (1) for truly exceptional situations and (2) as
> | a handy building block for higher-level things which one can use
> | without seeing the exceptions.
> 
> I hate circular discussions.  To break directly out of two nested
> for loops, we have exceptions.  If the only reason not to use them
> is purely stylistic - that is, we're unable to account for it in a
> practical way - it seems to me that the issue is resolved.  We have
> what we need, any time we want it.

Few things are *purely* stylistic. What we call a stylistic
preference is generally a particular way to resolve the
tradeoff between competing pressures. Those pressures are
different for different people (on account of what they're
used to seeing, or how their brain is built, or whatever),
so different "stylistic" preferences can actually be good
rational reasons for different people to act as they do.

For some people, "unexceptional" use of exceptions is bad
style. That means that they find it hard to follow, or that
they are bothered by the can't-always-tell-where-it's-come-from
nature of an exceptional control transfer. (That's why
exceptions are a little like gotos.) For others, exceptions
are a tool to be used whenever they're useful. Neither "side"
is just plain right or just plain wrong.

If "the issue" were: What should I do when I need to break
out of two nested loops? then I agree: there would be no
point whatever to this discussion. I think there was another
issue: would it be better if Python had some mechanism
for breaking out of nested loops that clearly and unambiguously
said what it was doing? You can't resolve this issue just
by saying "We have a mechanism for this, and it works OK";
that argument would lead to the conclusion that we don't
need ordinary single-level "break" either.

However, I reckon about four times as much has been said
in this thread as there's any use for, much of it by me.
So I'll shut up now. It's not as if this is important or
anything.

> | (But wasn't the discussion about whether using exceptions
> | that way isn't in fact confusing? Isn't that more than a
> | stylistic matter? Yes and no. What's confusing depends on
> | what you're used to. It's reasonable not to be used to a
> | heavily exception-based style even if you're writing Python,
> | and in that case using exceptions for normal control flow
> | will confuse you, and in that case you should avoid doing it.
> | <0.5 wink>)
> 
> I take that as parody, but there's some rationale for selectivity
> when you take on a programming language.  If you don't want or
> need the more obscure features, that's excellent as far as I'm
> concerned, we need more people like that.  But a core language
> feature like exceptions is kind of a must, you can't sensibly opt
> out.  What's left really is attitude.  I guess everyone has one.

Actually, it wasn't parody. I was trying (apparently not
very successfully) to say: those who aren't used to using
exceptions for ordinary control flow are likely to get
confused if they try, so they should maybe seek other ways
to express control flow (e.g., encapsulating nested loops
in a function and using "return"). I wasn't suggesting,
either seriously or in jest, that anyone using Python
should just not know about exceptions at all. That would
be daft.

-- 
Gareth McCaughan  Gareth.McCaughan at pobox.com
.sig under construc