for what are for/while else clauses

[Diez B. Roggisch]

Hi,

today I rummaged through the language spec to see whats in the for ... else:
for me. I was sort of disappointed to learn that the else clauses simply
gets executed after the loop-body - regardless of the loop beeing entered
or not.

So where is an actual use case for that feature?

I imagined that the else-clause would only be executed if the loop body
wasn't entered, so I could write this

for r in result:
print r
else:
print "Nothing found, dude!"

instead of

if len(result):
for r in result
print r
else:
print "Nothing found, dude!"



waiting for enlightment,

Diez

 

[David C. Fox]

Hi,

today I rummaged through the language spec to see whats in the for ... else:
for me. I was sort of disappointed to learn that the else clauses simply
gets executed after the loop-body - regardless of the loop beeing entered
or not.

I didn't realize that for...else existed, but according to the language
reference, the else clause gets executed unless the loop body exited due
to a break statement.

David

 

[Fredrik Lundh]

today I rummaged through the language spec to see whats in the for ... else:
for me. I was sort of disappointed to learn that the else clauses simply
gets executed after the loop-body - regardless of the loop beeing entered
or not.

So where is an actual use case for that feature?

for item in seq:
if item == target_item:
print "Found", item
break
else:
print "Nothing found, dude!"

I imagined that the else-clause would only be executed if the loop body
wasn't entered, so I could write this

for r in result:
print r
else:
print "Nothing found, dude!"

instead of

if len(result):
for r in result
print r
else:
print "Nothing found, dude!"

which is usually written as:

if result:
for r in result:
print r
else:
print "Nothing found, dude!"

or

if not result:
print "Nothing found, dude!"
else:
for r in result:
print r

</F>

 

[John Roth]

I didn't realize that for...else existed, but according to the language
reference, the else clause gets executed unless the loop body exited due
to a break statement.

Yep. It's one of the three termination conditions for a loop. The problem
is that it's a really bad name, and the termination condition I'm most
interested
in catching is the one where the loop didn't execute at all.

John Roth

 

[JCM]

Yep. It's one of the three termination conditions for a loop.

What are the three conditions? I know of two:

1 Reaching the end of the iteration
2 Breaking out

 

[Rene Pijlman]

Diez B. Roggisch:

today I rummaged through the language spec to see whats in the for ... else:
for me. I was sort of disappointed to learn that the else clauses simply
gets executed after the loop-body - regardless of the loop beeing entered
or not.

So where is an actual use case for that feature?

To execute code only when the loop terminates normally, not when it
terminates because of a break statement.

It's been discussed before:
http://groups.google.nl/[email protected]&rnum=3
http://groups.google.nl/[email protected]&rnum=7
http://groups.google.nl/groups?hl=n...=uofzrqjex.fsf%40ctwd0143.fitlinxx.com&rnum=7

 

[John Roth]

What are the three conditions? I know of two:

1 Reaching the end of the iteration
2 Breaking out

3. Not executing at all.

John Roth

 

[JCM]

3. Not executing at all.

I see that as an example of #1.

 

[John Roth]

I see that as an example of #1.

But it isn't. See what your code looks like with an
empty file, for example. Or even worse, see what it
would look like if you have to use a generator where
you can't test for an empty sequence.

John Roth

 

[Terry Reedy]

I imagined that the else-clause would only be executed if the loop body
wasn't entered, so I could write this ....
waiting for enlightment,

Try the following which I recently thought up.
You are familiar with this:

if cond: t()
else: f()

meaning, if cond is false, do f(). Now

while cond: t()
else: f()

means if and when cond is false, do f(). To make the parallel
clearer, consider this C-like pseudopython equivalent:

label: loop
if cond:
t()
goto loop
else: f()

If (and now when, because of the looping) cond is false, do f(). Now,

for i in seq: t()
else: f()

translates to something like

__i, __istop = 0, len(seq)
while __i < __istop:
i = seq[__i]
t()
else: f()

which in turn could be translated to an if with goto, so that f
executes if/when the sequence is exhausted.

In summary, the else clause executes if/when the loop condition
evaluates as false, just as with else clauses and if conditions. The
difference is the repeated instead of just once testing of the
condition. Break aborts this repeated testing and bypasses the else
clause, as it should because the condition was always true, as also
happens with true if conditions.

Terry J. Reedy

 

[Bryan]

I imagined that the else-clause would only be executed if the loop
body

wasn't entered, so I could write this
...

waiting for enlightment,

Try the following which I recently thought up.
You are familiar with this:

if cond: t()
else: f()

meaning, if cond is false, do f(). Now

while cond: t()
else: f()

means if and when cond is false, do f(). To make the parallel
clearer, consider this C-like pseudopython equivalent:

label: loop
if cond:
t()
goto loop
else: f()

If (and now when, because of the looping) cond is false, do f(). Now,

for i in seq: t()
else: f()

translates to something like

__i, __istop = 0, len(seq)
while __i < __istop:
i = seq[__i]
t()
else: f()

which in turn could be translated to an if with goto, so that f
executes if/when the sequence is exhausted.

In summary, the else clause executes if/when the loop condition
evaluates as false, just as with else clauses and if conditions. The
difference is the repeated instead of just once testing of the
condition. Break aborts this repeated testing and bypasses the else
clause, as it should because the condition was always true, as also
happens with true if conditions.

Terry J. Reedy

terry,

thnak you for your very clear and consice explanation.

bryan

 

[Michele Simionato]

I personally consider the "else" clause a wart of Python.
I never remember exactly what it is doing, and I have to look at the
manual each time; moreover I don't see it giving any significant advantage
to the language (other languages live very well without). So, I would be
happy to have it removed, even if I am sure it will never happen :-(
Am I the only one who think so?

Michele

 

[Erik Max Francis]

I personally consider the "else" clause a wart of Python.
I never remember exactly what it is doing, and I have to look at the
manual each time; moreover I don't see it giving any significant
advantage
to the language (other languages live very well without). So, I would
be
happy to have it removed, even if I am sure it will never happen :-(
Am I the only one who think so?

I actually like it, and have used it with the `for' and `while' control
structures (although I only recently found out it is also available with
`try' and had that functionality to EmPy). For some reason I can always
remember what it does, even though I agree it's not very memorable. I
will readily admit that `else' is not a particularly enlightening name
for the functionality it represents, but I'm not sure I could come up
with a one-word substitute that would be much more enlightening.

I do think it is highly ironic that a unified try...except...finally
construct was removed because it was allegedly not intuitive enough, but
for...else, while...else, and even try...except...else (!) stayed with
no such complaint.

--
Erik Max Francis && (e-mail address removed) && http://www.alcyone.com/max/
__ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
/ \
\__/ There's this perfect girl / Someone no one can see
-- Lamya

 

[Michele Simionato]

I do think it is highly ironic that a unified try...except...finally
construct was removed because it was allegedly not intuitive enough, but
for...else, while...else, and even try...except...else (!) stayed with
no such complaint.

It is strange that I do feel try...except...else very natural and I use
the construct all the time... mah!

My complaint is only against else in while and for.

Michele

 

[Alex Martelli]

I personally consider the "else" clause a wart of Python.

I think it depends on what statements we're talking about, but, yes,
restricting the discussion to for/else and while/else (if/else and
try/except/else being very different) I understand why you would.

I never remember exactly what it is doing, and I have to look at the

I haven't had the problem, myself, but I have seen others believe that the
else clause would run if the body was never run (for on an empty sequence,
while on a condition that's false since the first check), as in
(hypothetically)

for item in bought:
print 'Bought item', item
else:
print "No items were bought"

being short for

if bought:
for item in bought:
print 'Bought item', item
else:
print "No items were bought"

which might make sense (if bought were a non-reiterable, the if/else
construct has problems while the imaginary interpretation of the for/else
one would still work just fine). In this way, Python's for/else and
while/else do fail the least-astonishment test for at least some learners
(taking "else" to mean "no break was executed in the body" is hardly
obvious or most particularly "the only obvious" interpretation).

manual each time; moreover I don't see it giving any significant advantage
to the language (other languages live very well without). So, I would be

The fact that other languages lack a construct isn't necessarily
significant, of course -- most lack, e.g., classes as first-class objects,
yet Python's vastly better for having them. Still, it is indeed arguable
that for/else buys you little -- just a flag setting and checking when you
do use it, i.e., at most.

happy to have it removed, even if I am sure it will never happen :-(

Right, it's unlikely -- I haven't it seen proposed as a candidate to go
away in 3.0.

Am I the only one who think so?

Probably not; even though on the whole I disagree, I don't consider your
position at all "strange", nor my opposition particularly strong, therefore
I suspect that many at least mildly agree with you.

The classic homework one should do when considering a language
construct is "how is it used in the standard library". Have you examined
the uses of for/else and while/else there?


Alex

 

[Fredrik Lundh]

(taking "else" to mean "no break was executed in the body" is hardly
obvious or most particularly "the only obvious" interpretation).

that's not what it means, of course.

in every single case, it means "run once, if and only if the
controlling condition is false".

</F>

 

[JCM]

But it isn't. See what your code looks like with an
empty file, for example. Or even worse, see what it
would look like if you have to use a generator where
you can't test for an empty sequence.

Iterating over an empty file behaves as I expect--the loop terminates
after zero iterations, one time for each line. I'm not sure what you
mean about generators... If you have a generator that never yields
anything:

def g():
if 0:
yield 'nothing'

(is there a better way of writing one?)
then the loop

for x in g():
print x

also terminates after zero iterations.

 

[Alex Martelli]

that's not what it means, of course.

in every single case, it means "run once, if and only if the
controlling condition is false".

</F>

I'm not sure what you mean by "the controlling condition" in this case.

In a for/else or while/else construct, the only way to make your
assertion true is to define "the controlling condition" as "a break
[or return] interrupted the for or while loop [or an exception was
propagated]" -- basically (quibbles on returns and exceptions apart)
just what I said about "no break was executed".

A reasonably-common newbie error is to code, for example:

for purchase in purchases:
print 'Purchased:', purchase
else:
print "Nothing was purchased"

taking "the controlling condition" to be the obvious one, i.e., the
sequence the 'for' is iterating on. Or, similarly:

while current_value < threshold:
process_high_value(current_value)
current_value = compute_next_value()
else:
alert_no_high_values(threshold)

taking "the controlling condition" to be the obvious one, i.e., the
"current_value < threshold" conditions that controls the 'while'.

Python could presumably help a little by warning about an 'else' on
a for or while loop that contains no 'break' statements. But the
reason Python's for/else and while/else statements are not intuitive
to most people can be boiled down to identifying that "controlling
condition" -- the fact that the 'controlling condition' is "a break
statement has executed" is """hardly obvious or most particularly "the
only obvious" interpretation""", to repeat myself.


Alex

 

[Erik Max Francis]

that's not what it means, of course.

in every single case, it means "run once, if and only if the
controlling condition is false".

Where's the controlling condition in

for x in sequence:
...
else:
...

?

--
Erik Max Francis && (e-mail address removed) && http://www.alcyone.com/max/
__ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
/ \
\__/ Get married, but never to a man who is home all day.
-- George Bernard Shaw

 

[Fredrik Lundh]

I'm not sure what you mean by "the controlling condition" in this case.

the condition that controls if the conditional part of the statement
is executed. from what I can tell, that's the usual definition.

In a for/else or while/else construct, the only way to make your
assertion true is to define "the controlling condition" as "a break
[or return] interrupted the for or while loop [or an exception was
propagated]" -- basically (quibbles on returns and exceptions apart)
just what I said about "no break was executed".

for a while-statement, the controlling condition is the test at
the top.

for a for loop, the condition is "is there another item" (to quote the
language reference: "When the items are exhausted (which is imme-
diately when the sequence is empty) ... the loop terminates.".

for a try-except clause, the condition is "did the suite raise an
exception".

the fact that the 'controlling condition' is "a break statement
has executed"

that's not how it works.

</F>