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
33  3791 
Diez B. Roggisch wrote: 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
"David C. Fox" <da*******@post.harvard.edu> wrote in message
news:nr9tb.200590$Fm2.189136@attbi_s04... Diez B. Roggisch wrote:
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.
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
John Roth <ne********@jhrothjr.com> wrote:
.... 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
Diez B. Roggisch wrote: 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>
"JCM" <jo******************@myway.com> wrote in message
news:bp*********@fred.mathworks.com... John Roth <ne********@jhrothjr.com> wrote:
... 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
3. Not executing at all.
John Roth
John Roth <ne********@jhrothjr.com> wrote: "JCM" <jo******************@myway.com> wrote in message
news:bp*********@fred.mathworks.com... John Roth <ne********@jhrothjr.com> wrote:
... > 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
3. Not executing at all.
I see that as an example of #1.
"JCM" <jo******************@myway.com> wrote in message
news:bp**********@fred.mathworks.com... John Roth <ne********@jhrothjr.com> wrote:
"JCM" <jo******************@myway.com> wrote in message
news:bp*********@fred.mathworks.com... John Roth <ne********@jhrothjr.com> wrote:
...
> 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
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.
John Roth
"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 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
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
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
Erik Max Francis <ma*@alcyone.com> wrote in message news:<3F***************@alcyone.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
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
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>
John Roth <ne********@jhrothjr.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.
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_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
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
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>
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.
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>
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
(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
Fredrik Lundh wrote: 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
In article <ma************************************@python.org >,
"Fredrik Lundh" <fr*****@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
on confused.lang.python, Just 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:
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>
Alexander Schmolck wrote: 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
On Fri, 14 Nov 2003 19:31:08 +0100, "Diez B. Roggisch" <de************@web.de> wrote: 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
Fredrik Lundh wrote: 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 && ma*@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
In article <ma************************************@python.org >,
"Fredrik Lundh" <fr*****@pythonware.com> wrote: 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.
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.
Mel Wilson wrote: 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>
"Fredrik Lundh" <fr*****@pythonware.com> wrote in message news:<ma************************************@pytho n.org>... 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.
In article <25**************************@posting.google.com >,
Magnus Lyck? <ma****@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. aa**@pythoncraft.com (Aahz) wrote in message news:<bp**********@panix2.panix.com>... In article <25**************************@posting.google.com >,
Magnus Lyck? <ma****@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)
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. ma****@thinkware.se (Magnus Lyck?) wrote in message news:<25**************************@posting.google. com>... 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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Andrew Koenig |
last post by:
PEP 315 suggests that a statement such as
do:
x = foo()
while x != 0:
bar(x)
be equivalent to
while True:
|
by: Ron Adam |
last post by:
There seems to be a fair amount of discussion concerning flow control
enhancements lately. with, do and dowhile, case, etc... So here's my
flow control suggestion. ;-)
It occurred to me (a...
|
by: Mohanasundaram |
last post by:
Hi All,
I saw in some code
do{//for error jump
/*Some code here*/
}while(0);
Can anyone plese tell me what is the purpose of this code? There was a
comment saying that //for error jump....
|
by: ECathell |
last post by:
I had read an article at one time that suggested a pattern to get around deeply nested if..then..else hell...
Can anyone point me in that direction?
select case statements wont work for me in...
|
by: m.k.ball |
last post by:
Thanks Rich - that's great. Before I found this group, I thought I had
a reasonable understanding of SQL (well, MySQL's implementation of it,
at least) but the truth is there are great chunks that...
|
by: Curtiosity |
last post by:
I have done a create or replace view called creditcard1. If I do a "select * from creditcard1" it retrieves the data just fine. If I try to do a statement where I am listing the column names it...
|
by: Eighty |
last post by:
I suggest a new extension of the list comprehension syntax:
which would be equivalent to
list(itertools.takewhile(cond, xs))
+ Since Python favors list comprehensions over map, filter,...
|
by: metaperl.etc |
last post by:
A very old thread:
http://groups.google.com/group/comp.lang.python/browse_frm/thread/2c5022e2b7f05525/1542d2041257c47e?lnk=gst&q=for+else&rnum=9#1542d2041257c47e
discusses the optional "else:"...
|
by: Jyotirmoy Bhattacharya |
last post by:
I'm a newcomer to Python. I have just discovered nested list
comprehensions and I need help to understand how the if-clause
interacts with the multiple for-clauses. I have this small program:
...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |
