for what are for/while else clauses
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?
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
John Roth
"David C. Fox" <davi...@post.harvard.edu> wrote in message
news:nr9tb.200590$Fm2.189136@attbi_s04...
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
>
> David
>
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
>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/groups?q=%2Bfor+else+group:comp.lang.python&hl=nl&lr=&ie=UTF-8&oe=UTF-8&selm=slrn9teq1k.1vd.huaiyu%40gauss.almadan.ibm.com&rnum=3
http://groups.google.nl/groups?q=%2Bfor+else+group:comp.lang.python+break&hl=nl&lr=&ie=UTF-8&oe=UTF-8&selm=uofzrqjex.fsf%40ctwd0143.fitlinxx.com&rnum=7
http://groups.google.nl/groups?hl=nl&lr=&ie=UTF-8&oe=UTF-8&threadm=uofzrqjex.fsf%40ctwd0143.fitlinxx.com&rnum=7&prev=/groups%3Fq%3D%252Bfor%2Belse%2Bgroup:comp.lang.python%2Bbreak%26hl%3Dnl%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26selm%3Duofzrqjex.fsf%2540ctwd0143.fitlinxx.com%26rnum%3D7
--
René Pijlman
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
"JCM" <joshway_wi...@myway.com> wrote in message
news:bp3bmg$l3$1...@fred.mathworks.com...
John Roth
>
JCM
John Roth
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
"Diez B. Roggisch" <deets_n...@web.de> wrote in message
news:bp371c$g75$07$1...@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
Bryan
terry,
thnak you for your very clear and consice explanation.
bryan
Michele Simionato
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 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 && m...@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
> 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
>> >>
>> >> 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
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 && m...@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
> > 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>
Fredrik Lundh
> > in every single case, it means "run once, if and only if the
> > controlling condition is false".
>
> 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>
Alexander Schmolck
> 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:-).
Hmm, I can't see the break here:
>>> for x in []: print 'something'
... else: print 'nothing'
...
nothing
(Not that I wouldn't argue that the semantics of else in loops are blindingly
obvious, but I can see the (albeit slightly strained) analogy with if/else).
'as
Alex Martelli
> Alex Martelli wrote:
>
>> > in every single case, it means "run once, if and only if the
>> > controlling condition is false".
>>
>> 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.
We agree that it is the usual definition. We appear to disagree that
focusing on that condition is a sensible way to present (e.g.) the way
while/else works. E.g., consider:
>>> while avalue < another:
... print avalue,
... avalue += 1
... else:
... print 'else here'
...
versus
>>> while avalue < another:
... print avalue,
... avalue += 1
... if something(avalue, another): break
... else:
... print 'else here'
...
When somebody else "will the else clause execute", I would answer
(for the first case) "yes [if the loop ever terminates]" -- and for
the second case, "if and only if the break does not execute [i.e.,
if the 'something' test is never satisfied while the controlling
condition holds]".
In the first case, it would make no difference whatsoever to
recode the loop as:
while avalue < another:
print avalue,
avalue += 1
print 'foo here'
Again, "foo here" gets printed (as long as the loop ever terminates).
But in the second case, where a guarded 'break' is involved, the
transliteration is not feasible (you'd have to add a 'flag' variable
in order to remove the 'else' and keep the same semantics).
It seems misleading to me to focus on the controlling condition, i.e.,
on whether "avalue < another" is still true, or not. In the second
version of the loop it may perfectly well be true that the controlling
condition is false when the predicate 'something' is satisfied --
nevertheless, if the predicate is satisfied and thus the break
executes, the "else" clause does not execute.
>> 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.
In practice, it is (for both while and for, not for try; and net of
the already-interpolated distinguos about returns and exceptions).
When there is no 'break' in the loop's body, the 'else' clause is
useless: the body of the else clause would execute under exactly the
same conditions (i.e., if the loop ever terminates normally, w/o
return or exceptions) if the same statements were placed right after
the loop's end, rather than in an 'else' clause. The only practical
reason to ever have an 'else' clause on a for or while is to do
something different for a loop that terminates with a break, rather
than terminating "normally". Focusing on the 'break' being present
and executing therefore seems more practical to me, than focusing on
the "controlling condition" (which may be false without this fact
causing the 'else' clause to execute -- if a break intervenes).
Alex
Just
"Fredrik Lundh" <fre...@pythonware.com> wrote:
> > the fact that the 'controlling condition' is "a break statement
> > has executed"
>
> that's not how it works.
But it is: the only time the else clause is _not_ executed is when the
loop was stopped due to a break statement:
>>> for x in []:
... print x
... else:
... print "else"
...
else
>>> for x in [1]:
... print x
... else:
... print "else"
...
1
else
>>> for x in [1]:
... print x
... break
... else:
... print "else"
...
1
>>>
You're either speaking in tongues, or you're wrong. Am I missing
something?
Just
Fredrik Lundh
> > > the fact that the 'controlling condition' is "a break statement
> > > has executed"
> >
> > that's not how it works.
>
> But it is: the only time the else clause is _not_ executed is when the
> loop was stopped due to a break statement:
the break statement has nothing to do with the else clause; the else
is executed when there's no more item in the sequence. if you break
or raise or return or yield-and-never-resume or call-and-never-return
your way out of the loop doesn't matter.
read the C code if you don't believe me.
> You're either speaking in tongues, or you're wrong. Am I missing
> something?
like Alex, you're confusing cause and effect. don't do that; things are
easier to understand if you explain how they actually work.
</F>
Alex Martelli
> Alex Martelli <al...@aleax.it> writes:
>> 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:-).
>
> Hmm, I can't see the break here:
>
>>>> for x in []: print 'something'
> ... else: print 'nothing'
> ...
> nothing
Exactly because there is no 'break' in the loop's body, the 'else: '
clause-header is useless in this case; the code:
for x in []: print 'something'
print 'nothing'
(where the second print follows the whole loop rather than being
the body of its 'else' clause) would be quite equivalent.
> (Not that I wouldn't argue that the semantics of else in loops are
> blindingly obvious, but I can see the (albeit slightly strained) analogy
> with if/else).
If I squint hard enough I can see the similarity, sure, but I keep
thinking that "how do I _USE_ this language feature" is a more generally
useful viewpoint than "how is this language feature implemented". And
the (modest) _usefulness_ of the else clause on for and while loops is
inevitably connected to the possibility that a 'break' in the loop's
body may execute. If there is no such possibility, you might as well
just code the statements right after the whole loop, rather than putting
them in an else clause.
Alex
Michael Chermside
> the break statement has nothing to do with the else clause; the else
> is executed when there's no more item in the sequence. if you break
> or raise or return or yield-and-never-resume or call-and-never-return
> your way out of the loop doesn't matter.
>
> read the C code if you don't believe me.
> for a while-statement, the controlling condition is the test at
> the top.
Fredrik, I didn't try to go read the C code... instead I experimented
in Python:
def testWhileElse(exitViaBreak, condTrueAtExit):
print
print 'exitViaBreak = %s' % exitViaBreak
print 'condTrueAtExit = %s' % condTrueAtExit
if exitViaBreak:
loopCond = False
else:
loopCond = True
while loopCond:
if condTrueAtExit:
loopCond = True
break;
else:
print 'executed else clause'
According to this experiment, the only way to get "executed else clause"
to print is to set exitViaBreak to True. So I really don't understand
what you are claiming. Seems to me that the execution of the else
does NOT depend on the status of the loop condition at exit.
Besides which... the point made by Alex (among others) is a good one:
it doesn't matter how it's implemented under the covers... what matters
is how the writer/reader thinks of the code. And I've always thought
of the "else" on loops as having to do with the use or non-use of break
statements. And in this particular case I suspect that's how MOST Python
programmers think of it.
-- Michael Chermside
Bengt Richter
>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,
>
My mnemonic is to think of the mysterious elses as coming after prefixed pseudo-code like:
if this_code_is_interfered_with:
<loop code or try block>
else: # got to end of loop or end of try block without interference
hence
>>> for x in []: pass
... else: print 'got to end of nothing without interference ;-)'
...
got to end of nothing without interference ;-)
>>> try: pass
... except: pass
... else: print 'got to end of try: without interference.'
...
got to end of try: without interference.
>>> while raw_input('while> '):
... if raw_input('break? ')=='y': break
... else: print 'got to end of while w/o interference'
...
while> asdad
break? asad
while> asdasd
break?
while>
got to end of while w/o interference
>>> while raw_input('while> '):
... if raw_input('break? ')=='y': break
... else: print 'got to end of while w/o interference'
...
while> asd
break? y
Regards,
Bengt Richter
Erik Max Francis
> 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)
This hardly seems like a very good mnemonic, since the for...else
construct predates iterators.
The whole point here is that the behavior of for...else isn't
intuitively obvious. Sure, you can rationalize it after the fact, but
you have to be familiar with that rationalization to claim it makes
intuitive sense.
In the face of language rejections like try...except...finally,
for...else does not at all seem like something that is intuitively
obvious. (There's no doubt it's useful, but it's hardly transparent.)
--
Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/
__ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
/ \
\__/ It's only love that gets you through
-- Sade
Fredrik Lundh
> According to this experiment, the only way to get "executed else clause"
> to print is to set exitViaBreak to True. So I really don't understand what
> you are claiming. Seems to me that the execution of the else does NOT
> depend on the status of the loop condition at exit.
That's not what your program shows, though: if you set "exitViaBreak"
to true, your program sets the loop condition to false *before* it enters
the loop. In other words, your experiment shows that the else clause
runs when the loop condition is found to be false, and that it only runs
in that case.
Maybe you should read the C code, after all?
Or maybe this quote from a popular python book might help:
"Both the while and for statement may optionally have a trailing
else clause. The statement or statements after the else execute
when the loop terminates naturally (at the end of the for iterator
or when the while loop condition becomes false), but not when
the loop terminates prematurely (via break, return, or an exception).
(the author seems to have rebooted since he wrote that, though.)
</F>
Georgy Pruss
"Fredrik Lundh" <fre...@pythonware.com> wrote in message news:mailman.835.1069171...@python.org...
| <...>
| Or maybe this quote from a popular python book might help:
|
| "Both the while and for statement may optionally have a trailing
| else clause. The statement or statements after the else execute
| when the loop terminates naturally (at the end of the for iterator
| or when the while loop condition becomes false), but not when
| the loop terminates prematurely (via break, return, or an exception).
|
| (the author seems to have rebooted since he wrote that, though.)
|
| </F>
The 'else' part of for/while is VERY useful and this is of course a big
plus for Python. But the name 'else' is VERY misleading and useless
and is probable even worse than 'static' in C++. That's exectly why
every week somebody asks this question here again and again.
I'm sure, even something like 'on_nornal_exit' would be much much better.
--
Georgy Pruss
E~mail: 'ZDAwMTEyMHQwMzMwQGhvdG1haWwuY29t\n'.decode('base64')
Mel Wilson
>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".
Interesting way to think about it. Thanks.
So in some sample code:
while some_condition:
some_action ()
else:
last_action ()
following_code ()
If the loop results in some_action being done, say, 17
times; then that means that some_condition was found true 17
times. The 18th time, some_condition is found to be false,
the else takes effect and last_action gets done one time.
The only wrinkle then is that the while loop construct
passes control to the following code after that one
last_action. But we expect that from a while loop.
The effect of a break in the suite controlled by the
while is to blow away execution of the whole while
construct, including the else.
As an explanation, I like it.
Regards. Mel.
Fredrik Lundh
> >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".
>
> Interesting way to think about it. Thanks.
>
> So in some sample code:
>
> while some_condition:
> some_action ()
> else:
> last_action ()
> following_code ()
>
> If the loop results in some_action being done, say, 17
> times; then that means that some_condition was found true 17
> times. The 18th time, some_condition is found to be false,
> the else takes effect and last_action gets done one time.
imagine a dialect of Python that supports C-style goto's and labels.
in this dialect,
while some_condition:
some_action ()
else:
last_action ()
can be rewritten as
this_statement:
if some_condition:
some_action ()
goto this_statement
else:
last_action ()
next_statement:
(which, of course, is exactly what Python's current compiler does, but
on the bytecode level).
"break" and "continue" can now be rewritten as "goto next_statement"
and "goto this_statement".
for "for-in" and "try-except", the code calculating the "some_condition"
value is a bit different, but the rest works in exactly the same way.
here's the for-in version:
<set up the iterator>
this_statement:
<fetch next value from iterator>
if <value found>:
variable = <value>
some_action ()
goto this_statement
else:
last_action ()
next_statement:
and here's the try-except version (somewhat simplified):
this_statement:
<enable error handling>
some_action ()
error_handler:
<disable error handling>
if <matching error occurred>:
some_action ()
else:
other_action ()
> The only wrinkle then is that the while loop construct
> passes control to the following code after that one
> last_action. But we expect that from a while loop.
most Python statements pass control to the next statement
when they're done.
> The effect of a break in the suite controlled by the
> while is to blow away execution of the whole while
> construct, including the else.
>
> As an explanation, I like it.
me too.
</F>
Magnus Lyck?
> the break statement has nothing to do with the else clause; the else
> is executed when there's no more item in the sequence. if you break
> or raise or return or yield-and-never-resume or call-and-never-return
> your way out of the loop doesn't matter.
On the other hand, I only think it's in the case of a break
in block that...
while condition:
block
else:
print "Loop finished"
...will behave differently than...
while condition:
block
print "Loop finished"
So, unless you use a break in the block, the else statement
is just noise: an extra line of code and additional whitespace
for the following statement(s).
It's only together with the python idiom of breaking out of
loops with ifs (which is considered bad form in some (non
python) circles that the else part of the for and while statements
make sense.
Aahz
Magnus Lyck? <mag...@thinkware.se> wrote:
>
>On the other hand, I only think it's in the case of a break
>in block that...
>
>while condition:
> block
>else:
> print "Loop finished"
>
>...will behave differently than...
>
>while condition:
> block
>print "Loop finished"
>
>So, unless you use a break in the block, the else statement is just
>noise: an extra line of code and additional whitespace for the
>following statement(s).
While technically correct, I don't think you could claim that it's "just
noise" in this example:
try:
for ORlist in includes:
try:
for filter in ORlist:
for field in curr_fields:
for item in record[field]:
if match(item, filter):
raise Found
else:
raise NotFound
except Found:
continue
except NotFound:
continue
else:
result.append(record)
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
Weinberg's Second Law: If builders built buildings the way programmers wrote
programs, then the first woodpecker that came along would destroy civilization.
Magnus Lyck?
First of all, I'm not sure it's a good idea to use
exceptions like a poor (rich?) man's GOTO like this. :)
If you persist, I'm not so sure your code is clearer than:
try:
for ORlist in includes:
try:
for filter in ORlist:
for field in curr_fields:
for item in record[field]:
if match(item, filter):
raise Found
raise NotFound
except Found:
continue
except NotFound:
continue
else:
result.append(record)
With the else clause on the for loop, just after the if
statement, you are bound to confuse people. I would guess
that most people who casually looked at that code would
think that you had made an indentation mistake. Some would
probably "correct" it.
Michele Simionato
> First of all, I'm not sure it's a good idea to use
> exceptions like a poor (rich?) man's GOTO like this. :)
>
> If you persist, I'm not so sure your code is clearer than:
>
> try:
> for ORlist in includes:
> try:
> for filter in ORlist:
> for field in curr_fields:
> for item in record[field]:
> if match(item, filter):
> raise Found
> raise NotFound
> except Found:
> continue
> except NotFound:
> continue
> else:
> result.append(record)
>
> With the else clause on the for loop, just after the if
> statement, you are bound to confuse people. I would guess
> that most people who casually looked at that code would
> think that you had made an indentation mistake. Some would
> probably "correct" it.
I, for one, could get confused. BTW, I don't remember a single case in
all my code where I have used so much indentation. I would write some
helper function and avoid nesting as much as possible.
Michelee