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

[Bryan]

Terry Reedy wrote:

"Diez B. Roggisch" <de************ @web.de> wrote in message
news:bp******** *****@news.t-online.com...

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]

Michele Simionato wrote:

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 && ma*@alcyone.com && 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]

Erik Max Francis <ma*@alcyone.co m> wrote in message news:<3F******* ********@alcyon e.com>...

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]

Michele Simionato wrote:

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]

Alex Martelli wrote:

(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]

John Roth <ne********@jhr othjr.com> wrote:
....

>> What are the three conditions? I know of two:
>>
>> 1 Reaching the end of the iteration
>> 2 Breaking out
> 3. Not executing at all.
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.

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]

Fredrik Lundh wrote:

Alex Martelli wrote:

(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>

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_va lue(current_val ue)
current_value = compute_next_va lue()
else:
alert_no_high_v alues(threshold )

taking "the controlling condition" to be the obvious one, i.e., the
"current_va lue < 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 "controllin g
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]

Fredrik Lundh wrote:

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 && ma*@alcyone.com && 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]

Erik Max Francis wrote:

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:
...

?

you mean you don't know how the for-loop checks if there's
another item in the sequence?

(hint: look for StopIteration in the docs)

</F>