1.5.2 for: else:

[William Tanksley]

On 27 Jul 1999 23:33:58 GMT, Donn Cave wrote:
>wtanksle at dolphin.openprojects.net (William Tanksley) writes:
>|On Tue, 27 Jul 1999 14:29:43 +0200, Thomas Wouters wrote:

>|> http://www.python.org/doc/current/tut/node6.html#SECTION006200000000000000000

>|> 4.4 break and continue Statements, and else Clauses on Loops 

>|> Loop statements may have an else clause; it is executed when the loop
>|> terminates through exhaustion of the list (with for) or when the condition
>|> becomes false (with while), but not when the loop is terminated by a break
>|> statement. 

>| Well, I'm suprised.  I had also expected the else clause to run on empty
>| loop.  It seems so natural, in line with the meaning of a loop (loop on
>| this; otherwise do that).

>| Fortunately I've never actually used it and thus been disenchanted.

>[(I'm confused? else clause _does_ execute after an empty loop, like
>   for x in ():
>       pass
>   else:
>       print 'for else'
>)]

Of course.  It also executes on a full loop, or a half-full one, or for
that matter a half-empty one.  The only time it doesn't execute is when
the code block _inside_ the loop happens to execute a break.  Pretty odd
when you think about it.

>It seems to me to work the only useful way,

I'm sorry, I'm allergic to that phrase.  I can't deny that it's useful
now, but anyone claiming that any current condition is the ONLY useful
way...  Ugh.  Obviously hasn't bothered even thinking about alternatives.

If there existed even a _less_ useful way you'd be wrong.  And even
supposing myself to be wrong, there does exist such a way.  QED.

>so you almost can't
>go wrong - at worst, if you mistake its meaning, you won't use it.

That's the problem!  You _will_ use it, under the mistaken impression that
it performs some kind of useful 'else' function.  Instead it performs a
hidden exception-handling.  Was this leftover from some time when Python
didn't have exception handling or something?

>That may not be the same thing as "natural", but it's close.

I'm also allergic to "intuitive", and since I nearly used the word myself,
my sinuses are completely plugged.  ;-)

I can't really claim natural behavior, but I do claim that both of our
problems are easily solved using other means, and my solution is
consistent with other uses of else while the current solution isn't.  On
your side, of course, is the fact that the current solution IS the current
solution, no ifs ands ors or elses about it.

>It's one of the neat little things that make me pause for a moment
>of appreciation when I get to use it.

I'm pausing right now for a moment of appreciation.  No, this is
incredulity.  What is it about this that makes you appreciate it?  I can't
see anything in it except a world-class kludge.  The alternate solution,
throwing an exception, is SO much nicer that very few people even USE the
current behavior.

>| Understanding the current semantics seems to require understanding the
>| nature of loop tests in Python.  Since I understand them I can agree that
>| this makes sense, but I'm still a bit leery, because you're not 'elsing'
>| on the data but rather on code inside the loop.

>| I would _definitely_ use exceptions to handle this.

>Note that "try/except" also takes an "else", which also happens to have
>the only useful sense

Hack, ack, sniffle.  ;)

>and executes when the try block executes with no
>exception.  It's handy for code that should execute in the normal case
>but does not itself need to be enclosed in an exception handler, so you
>can focus the try block more precisely on the section that needs it.

I agree.  It's a wonderfully useful tool, and unlike either of our
solutions is pretty much irreplacable.  Not as useful as 'finally', of
course.

It shares a characteristic with my solution: it executes only when the
previous control structure's block has failed to execute.

>	Donn Cave, University Computing Services, University of Washington

-- 
-William "Billy" Tanksley