The rap against "while True:" loops
kj
I'm coaching a group of biologists on basic Python scripting. One
of my charges mentioned that he had come across the advice never
to use loops beginning with "while True". Of course, that's one
way to start an infinite loop, but this seems hardly a sufficient
reason to avoid the construct altogether, as long as one includes
an exit that is always reached. (Actually, come to think of it,
there are many situations in which a bona fide infinite loops
(typically within a try: block) is the required construct, e.g.
when implementing an event loop.)
I use "while True"-loops often, and intend to continue doing this
"while True", but I'm curious to know: how widespread is the
injunction against such loops? Has it reached the status of "best
practice"?
TIA!
kynn
Mensanator
If you know this "exit that is always reached",
why do you pretend not to know it by writing
"while True"?
>
> TIA!
>
> kynn
kj
>On Oct 10, 3:15=EF=BF=BDpm, kj <no.em...@please.post> wrote:
>> I'm coaching a group of biologists on basic Python scripting. =EF=BF=BDOn=
>e
>> of my charges mentioned that he had come across the advice never
>> to use loops beginning with "while True". =EF=BF=BDOf course, that's one
>> way to start an infinite loop, but this seems hardly a sufficient
>> reason to avoid the construct altogether, as long as one includes
>> an exit that is always reached. =EF=BF=BD(Actually, come to think of it,
>> there are many situations in which a bona fide infinite loops
>> (typically within a try: block) is the required construct, e.g.
>> when implementing an event loop.)
>>
>> I use "while True"-loops often, and intend to continue doing this
>> "while True", but I'm curious to know: how widespread is the
>> injunction against such loops? =EF=BF=BDHas it reached the status of "bes=
>t
>> practice"?
>If you know this "exit that is always reached",
>why do you pretend not to know it by writing
>"while True"?
There's no "pretense" of anything. I just happen to prefer the
directness of this:
while True:
...
if test_that_always_succeeds_eventually():
break
...
over the unnecessary fussiness of this:
my_prissy_little_indicator_variable = True
while my_prissy_little_indicator_variable:
...
if test_that_always_succeeds_eventually():
my_prissy_little_indicator_variable = False
continue # oh boy this is going to be fun!
...
In fact, if it were up to me, I would have made the fundamental
looping construct something like
repeat:
...
if whatever():
break
...
and made all the other looping constructs as syntatic sugar for
this one.
kj
Björn Lindqvist
a safe exit condition which turned out to be never reached in some
rare corner cases. Leading to weird bugs with hanging threads. I have
seen colleges screw up in the same way too. Often it is possible to
reformulate "while True" to a generator which I think is much
preferable (such as in the event loop example). Recursive functions
can also be more readable than "while True" because it is easier to
make the exit condition explicit. But sometimes they are necessary and
then you have to be careful to check that the "while True" always
breaks somewhere.
2009/10/10 kj <no.e...@please.post>:
> --
> http://mail.python.org/mailman/listinfo/python-list
>
--
mvh Björn
Mensanator
So, the second set of '...' doesn't get executed.
When I use
while not done:
...
if n==1: done = True
...
the loop will actually complete (which is what
I want) instead of aborting, like yours does.
I just don't want the loop to execute again.
If there are things that should not be done,
I explicity have the code check that:
...
if not done: write_to_file(test)
...
But even if some things are skipped, others
need not be:
....
n += 1
...
Now, if I did a break before writing to the file,
I would have to do all kinds of clean-up code
outside the loop, code that would be run only
if the exit were abnormal.
>
> and made all the other looping constructs as syntatic sugar for
> this one.
Luckily, it's not up to you.
>
> kj
Peter Billam
> I use "while True"-loops often, and intend to continue doing this
> "while True", but I'm curious to know: how widespread is the
> injunction against such loops? Has it reached the status of
> "best practice"?
This trend is ironic; I remember in the structured-programming
revolution the
loop { ... if whatever {break;} ... }
idiom was The Recommended looping structure, because the code is
more maintainable. With a while () {...} idiom, you commit
yourself to a bug-prone rewrite if you ever need to insert a
statement before the first break-test, and likewise with a
repeat { ... } until () you commit yourself to a rewrite if
you ever need to insert a statement after the last break-test.
Also, it replaces a multitude of idioms (while, repeat, for,
foreach, map, ...) with one simple idiom which works in all
cases, including in all languages (OK, except functional).
The for item in list idiom is wonderfully readable if you
know that's all you'll ever want to do, but for more general
loops there are still arguments in favour of while True
Infinite loops, well they're quickly noticed in development,
just like stack-crashes are in stack-based languages.
They can occur in other loop-idioms too, like if you
append to your list, or adjust the looping index.
JMHO, Regards, Peter
--
Peter Billam www.pjb.com.au www.pjb.com.au/comp/contact.html
Terry Reedy
>
> I use "while True"-loops often, and intend to continue doing this
> "while True",
Me too. Of course, in Python, 'while True' actually means 'while ^C not
pressed and window not closed and process not killed:',
whereas in old mainframe Fortran the equivalent might have meant 'while
my account not emptied', which tended to engender a fear of such loops.
tjr
Bearophile
> I remember in the structured-programming revolution the
> loop { ... if whatever {break;} ... }
> idiom was The Recommended looping structure, because the code is
> more maintainable.
I think "break" was almost the antithesis of structured programming,
it was seen as the little (and a bit more well behaved) brother of
"goto".
Too many "breaks" turn code almost into Spaghetti, that is the
opposite of structured programming.
> With a while () {...} idiom, you commit
> yourself to a bug-prone rewrite if you ever need to insert a
> statement before the first break-test, and likewise with a
> repeat { ... } until () you commit yourself to a rewrite if
> you ever need to insert a statement after the last break-test.
I think while True:... is used often in Python because Python lacks
still a do-while (or repeat-until, but this is less nice, because the
condition is reversed compared to the one you use in a while-do loop)
construct.
Give me a do-while and a good amount of breaks&while True in my Python
code will be removed.
Bye,
bearophile
Hendrik van Rooyen
Others have given various valid answers, but I have not seen this one:
It is often necessary, in long running applications, to set up loops that you
would really like to run until the end of time. - the equivalent of a "serve
forever" construct. Then while True is the obvious way to spell it.
- Hendrik
Steven D'Aprano
> I use "while True"-loops often, and intend to continue doing this "while
> True", but I'm curious to know: how widespread is the injunction against
> such loops? Has it reached the status of "best practice"?
Such an injunction probably made more sense back in the days of single-
tasking computers. Back in ancient days when dinosaurs walked the Earth,
and I was programming in THINK Pascal on Apple Macintosh System 6, I'd go
into nervous palpitations writing the equivalent of "while True" because
if I got it wrong, I'd lock up the machine and need to hit the power
button. (At least if I was still testing in the THINK Pascal IDE, and had
the whole range of debugging options turned on, I could interrupt it.)
These days, I must admit I still have a tiny little shiver whenever I
write "while True", but that's entirely irrational and I pay no attention
to it.
--
Steven
Peter Billam
> Peter Billam:
>> I remember in the structured-programming revolution the
>> loop { ... if whatever {break;} ... }
>> idiom was The Recommended looping structure, because the code is
>> more maintainable.
>
> I think "break" was almost the antithesis of structured programming,
> it was seen as the little (and a bit more well behaved) brother
> of "goto". Too many "breaks" turn code almost into Spaghetti,
> that is the opposite of structured programming.
It's multi-level breaks that are danger-prone and were
deprecated; a single-level break is quite safe.
> Give me a do-while and a good amount of breaks&while True
> in my Python code will be removed.
Maybe, but you still commit yourself to a rewrite if you
ever need to insert a statement after the last break-test.
It needs only one tiny extra little requirement in the
wrong place to invalidate a while or a do structure,
but the loop-and-break structure always works,
and that's what gives it its extra maintainability.
Grant Edwards
>
> It is often necessary, in long running applications, to set up
> loops that you would really like to run until the end of time.
> - the equivalent of a "serve forever" construct. Then while
> True is the obvious way to spell it.
Once upon a time I was working on the software requirements
specifications for a missile launcher for the US Navy. In the
section on the system's scheduler task I wrote something like
this:
The scheduler shall consist of an infinite loop that executes
the following:
1. Call this function.
2. Call that function.
[...]
The review team (mainly from Johns Hopkins University Applied
Physics Lab) told me I couldn't put an infinite loop in the
requirements document.
I replied, "OK, when or under what circumstances do you want
the launcher to stop working?"
They said that I misunderstood their comment. I can (and
indeed must) have an infinite loop in the software. I just
can't put the phrase "infinite loop" in the document. They
explained that ship captains get to review these documents.
Ship captains all took a year of undergrad FORTRAN programming
and therefore believe that an infinite loop is a bad thing.
I changed the text to read something like this:
The secheduler shall repeatedly execute the following until
the system is powered off or reset:
1. Call this function.
2. Call that function.
[...]
Everybody was happy.
Tax dollars at work...
--
Grant
Gabriel Genellina
escribiￜ:
> I have many times screwed up "while True"-loops. When I thought I had
> a safe exit condition which turned out to be never reached in some
> rare corner cases. Leading to weird bugs with hanging threads. I have
> seen colleges screw up in the same way too.
But that's not a problem with the "while True:" construct, that's a
problem with your condition. Had you written the code using "while
some_condition:" it would have failed in the same way.
> [...] Recursive functions
> can also be more readable than "while True" because it is easier to
> make the exit condition explicit. But sometimes they are necessary and
> then you have to be careful to check that the "while True" always
> breaks somewhere.
That's true for any loop. The only difference is, with a "while
condition:" loop, the condition is right at the while statement. In a
"while True:" loop, you have to look for the condition elsewhere (likely,
an "if" statement preceding a "break").
--
Gabriel Genellina
bartc
When I'm starting to code something I haven't yet fully worked out, it often
starts with an infinite loop like this, until the body is coded and I've
figured out how to escape from it.
At the end if may or may not be tidied up, depending on how much work it is
to reconcile several possible break points into a single terminating
condition to be place at one end, and whether that is likely to break or
obfuscate a currently working program.
But if it's never going to be seen by the brigade who hate all break, exit,
goto and multiple return statements, then I won't bother.
--
Bartc
Mensanator
> Mensanator wrote:
> > On Oct 10, 3:15 pm, kj <no.em...@please.post> wrote:
> >> I'm coaching a group of biologists on basic Python scripting. One
> >> of my charges mentioned that he had come across the advice never
> >> to use loops beginning with "while True". Of course, that's one
> >> way to start an infinite loop, but this seems hardly a sufficient
> >> reason to avoid the construct altogether, as long as one includes
> >> an exit that is always reached. (Actually, come to think of it,
> >> there are many situations in which a bona fide infinite loops
> >> (typically within a try: block) is the required construct, e.g.
> >> when implementing an event loop.)
>
> >> I use "while True"-loops often, and intend to continue doing this
> >> "while True", but I'm curious to know: how widespread is the
> >> injunction against such loops? Has it reached the status of "best
> >> practice"?
>
> > If you know this "exit that is always reached",
> > why do you pretend not to know it by writing
> > "while True"?
>
> When I'm starting to code something I haven't yet fully worked out, it often
> starts with an infinite loop like this, until the body is coded and I've
> figured out how to escape from it.
And when I'm in the early stages of a
while not done:
loop, it performs the exact same functionality
while I'm working out what the terminating
conditions are.
>
> At the end if may or may not be tidied up, depending on how much work it is
> to reconcile several possible break points into a single terminating
> condition to be place at one end, and whether that is likely to break or
> obfuscate a currently working program.
Yes, that's a problem and is a good reason to
avoid doing such a thing. With multiple breaks,
your loop may not properly terminates which may
put an unecessary burden on the code which
follows the loop. Seeing the trees is important,
but not at the expense of the forest.
>
> But if it's never going to be seen by the brigade who hate all break, exit,
> goto and multiple return statements, then I won't bother.
Fine, but the OP is coaching others on how to
program. I've not seen any evidence in this thread
that "while true" is considered "best practice".
>
> --
> Bartc
Philip Semanchuk
I think you bring up a good point. I think "while True" has some
legitimate uses (like event loops), and I don't mind seeing it there.
What I don't like is goto, and to a lesser extent break, exit, and
multiple returns. I don't find too many cases where they're the
clearest way to express things. And where one sees a "while True", one
can almost always find a "break" or two lurking in the loop.
IMHO, break, goto, etc. have their place, but they're ripe for abuse
which leads to spaghetti code. Since the OP is teaching non-
programmers to write code, I think the potential for abuse is
especially important to keep in mind. I'd think that teaching them a
tool like "while True" would encourage the "code now, design later"
trap that even experienced programmers -- including myself --
sometimes fall into. Writing "while <condition>" instead forces one to
stop at the beginning of the loop and think at least a little about
exactly what it's meant to accomplish.
In addition, isn't it easier to figure out how this loop ends --
while (condition1) and (condition2) and (condition3):
...lots of code here...
than this one?
while True:
...lots of code here...
if not condition1:
break
...lots of code here...
if not condition2:
break
...lots of code here...
if not condition3:
break
My $.02,
Philip
RDrewD
I was a bit surprised that nobody in this discussion so far bantered
around the phrase "loop invariant", but then I looked in
http://en.wikipedia.org/wiki/Loop_invariant and found it was draped in
so much formalism that it's sure to put off all but the most dedicated
of Computer Science fans. I haven't been in college in 35 years, so
I'll admit to being rusty on this, but as I remember it, any time we
wrote a loop, we were expected to be able to say what the loop
invariant is.
my_prissy_little_indicator_variable = true
while (my_prissy_little_indicator_variable){
<body>
}
isn't satisfying because it doesn't guard the <body> with any
assurance that the loop invariant will be true before you enter into
that block of code.
Similarly, the
Repeat {
<first part>
if (<exit condition>) break
<second part>
}
doesn't guard the <first part> code. Worse, when you get to the
Repeat in reading the code, you get no clue about when the loop will
terminate, except maybe for a comment that someone helpfully put by
the loop, but as the program evolves, the comments often lie.
I don't mind while(true) for the case of "do forever" like those
launcher requirements Peter Billam wrote about up above in this
thread. It essentially says the loop invariant is that the system
hasn't crashed yet. But beware of the "universal structured
program":
pc=1
while(pc!=0){
select(pc){
case 1:
<body1>
pc=<next block #>
continue
case 2:
<body2>
....
}
}
# Look Ma! No goto statements
There are no goto statements but the "universal structured program"
has no meaningful "structure" visible to the casual reader's eye..
By making the setting of PC in each case be conditional, you can send
the program to any <bodyN> that you want. (Think of pc as standing
for "program counter" and you can see this has as much structure as
assembler language. Very hard to judge that the code always keeps
array references within bounds and that all loops are only entered
when the loop invariant holds and that the loops always terminate when
the loop invariant no longer holds. You might as well be programming
like its 1959. See, it wasn't just the presence of goto's that was
harmful, it was the lack of careful construction of the program that
was harmful.
And just to dust off a fun paper from the past that explores
programming structures that might be needed if you care about every
last branch instruction as you carefully construct your program, see
http://pplab.snu.ac.kr/courses/adv_pl05/papers/p261-knuth.pdf, Knuth's
classic "Structured Programming with Go To statements". ("Do you
suffer from painful elimination?").
R. Drew Davis
Cornell '74
Bell Labs, "retired".
Gabriel Genellina
<phi...@semanchuk.com> escribió:
> On Oct 11, 2009, at 5:51 PM, bartc wrote:
>>> On Oct 10, 3:15�pm, kj <no.em...@please.post> wrote:
>>>> I'm coaching a group of biologists on basic Python scripting. �One
>>>> of my charges mentioned that he had come across the advice never
>>>> to use loops beginning with "while True".[...]
>>>
>>> If you know this "exit that is always reached",
>>> why do you pretend not to know it by writing
>>> "while True"?
>>
>> When I'm starting to code something I haven't yet fully worked out, it
>> often starts with an infinite loop like this, until the body is coded
>> and I've figured out how to escape from it.
>>
>> At the end if may or may not be tidied up, depending on how much work
>> it is to reconcile several possible break points into a single
>> terminating condition to be place at one end, and whether that is
>> likely to break or obfuscate a currently working program.
>
> I think you bring up a good point. I think "while True" has some
> legitimate uses (like event loops), and I don't mind seeing it there.
> What I don't like is goto, and to a lesser extent break, exit, and
> multiple returns. I don't find too many cases where they're the clearest
> way to express things. And where one sees a "while True", one can almost
> always find a "break" or two lurking in the loop.
>
> IMHO, break, goto, etc. have their place, but they're ripe for abuse
> which leads to spaghetti code. Since the OP is teaching non-programmers
> to write code, I think the potential for abuse is especially important
> to keep in mind. I'd think that teaching them a tool like "while True"
> would encourage the "code now, design later" trap that even experienced
> programmers -- including myself -- sometimes fall into. Writing "while
> <condition>" instead forces one to stop at the beginning of the loop and
> think at least a little about exactly what it's meant to accomplish.
I don't think so; forcing ALL loops to have the condition at the start is
unnatural in some cases. Some loops are best written with the condition at
the end (do/while or repeat/until in Pascal) and some loops require a test
in the middle (in Python, while True: + break, because we don't have an
unconditional loop).
> In addition, isn't it easier to figure out how this loop ends --
>
> while (condition1) and (condition2) and (condition3):
> ...lots of code here...
>
> than this one?
>
> while True:
> ...lots of code here...
> if not condition1:
> break
> ...lots of code here...
> if not condition2:
> break
> ...lots of code here...
> if not condition3:
> break
For a loop that can be written as the first one above, sure, that's pretty
explicit.
For a loop as the second one, try to rewrite it with the condition at the
start: you'll end with duplicated tests and/or duplicated code and/or
artificial boolean variables added.
Some algorithms are *naturally* expressed as a loop with the condition in
the middle. Forcing the condition to always happen at the start requires
artificial steps that complicate unnecesarily the code.
--
Gabriel Genellina
Gabriel Genellina
> On Oct 11, 6:46ï¿œpm, Philip Semanchuk <phi...@semanchuk.com> wrote:
>> On Oct 11, 2009, at 5:51 PM, bartc wrote:
>> > Mensanator wrote:
>> >> On Oct 10, 3:15 pm, kj <no.em...@please.post> wrote:
>> >>> I'm coaching a group of biologists on basic Python scripting. One
>> >>> of my charges mentioned that he had come across the advice never
>> >>> to use loops beginning with "while True". Of course, that's one
>> >>> way to start an infinite loop, but this seems hardly a sufficient
>> >>> reason to avoid the construct altogether, as long as one includes
>> >>> an exit that is always reached. (Actually, come to think of it,
>> >>> there are many situations in which a bona fide infinite loops
>> >>> (typically within a try: block) is the required construct, e.g.
>> >>> when implementing an event loop.)
>>
>> >>> I use "while True"-loops often, and intend to continue doing this
>> >>> "while True", but I'm curious to know: how widespread is the
>> >>> injunction against such loops? Has it reached the status of "best
>> >>> practice"?
>>
>> >> If you know this "exit that is always reached",
>> >> why do you pretend not to know it by writing
>> >> "while True"?
>>
>> > When I'm starting to code something I haven't yet fully worked out, ￜ
>> > it often starts with an infinite loop like this, until the body is ￜ
>> > coded and I've figured out how to escape from it.
>>
>> > At the end if may or may not be tidied up, depending on how much ￜ
>> > work it is to reconcile several possible break points into a single ￜ
>> > terminating condition to be place at one end, and whether that is ￜ
>> > likely to break or obfuscate a currently working program.
>>
>> > But if it's never going to be seen by the brigade who hate all ￜ
>> > break, exit, goto and multiple return statements, then I won't bother.
>>
>> I think you bring up a good point. I think "while True" has some ￜ
>> legitimate uses (like event loops), and I don't mind seeing it there. ￜ
>> What I don't like is goto, and to a lesser extent break, exit, and ￜ
>> multiple returns. I don't find too many cases where they're the ￜ
>> clearest way to express things. And where one sees a "while True", one ￜ
>> can almost always find a "break" or two lurking in the loop.
>>
>> IMHO, break, goto, etc. have their place, but they're ripe for abuse ￜ
>> which leads to spaghetti code. Since the OP is teaching non-
>> programmers to write code, I think the potential for abuse is ￜ
>> especially important to keep in mind. I'd think that teaching them a ￜ
>> tool like "while True" would encourage the "code now, design later" ￜ
>> trap that even experienced programmers -- including myself -- ￜ
>> sometimes fall into. Writing "while <condition>" instead forces one to ￜ
>> stop at the beginning of the loop and think at least a little about ￜ
>> exactly what it's meant to accomplish.
>
> I was a bit surprised that nobody in this discussion so far bantered
> around the phrase "loop invariant", but then I looked in
> http://en.wikipedia.org/wiki/Loop_invariant and found it was draped in
> so much formalism that it's sure to put off all but the most dedicated
> of Computer Science fans. I haven't been in college in 35 years, so
> I'll admit to being rusty on this, but as I remember it, any time we
> wrote a loop, we were expected to be able to say what the loop
> invariant is.
>
> my_prissy_little_indicator_variable = true
> while (my_prissy_little_indicator_variable){
> <body>
> }
> isn't satisfying because it doesn't guard the <body> with any
> assurance that the loop invariant will be true before you enter into
> that block of code.
I think you meant the other way; the above is the simplest loop case, with
the test at the start. A loop with the test at the end, on the other hand,
is slightly harder to prove correct (but not much).
As an example, Ada has a general loop construct like this:
loop
...
exit when some_condition;
...
end loop;
and LOTS of work has been done in proving correctness of Ada programs, so
having the test at the start/middle/end of the loop is not an obstacle for
formal verification.
--
Gabriel Genellina
greg
> Back in ancient days when dinosaurs walked the Earth,
> and I was programming in THINK Pascal on Apple Macintosh System 6, I'd go
> into nervous palpitations writing the equivalent of "while True" because
> if I got it wrong, I'd lock up the machine and need to hit the power
> button.
That was true when just about *anything* went wrong in that
environment, though -- I don't think you can blame while True
in particular for it.
(I remember my earliest Mac programming experiences, back
when the Mac was too small to run its own development
environment, and everything had to be cross-compiled.
Debugging consisted of counting the number of times
SysBeep got called before the bomb icon appeared...)
--
Greg
greg
> my_prissy_little_indicator_variable = true
> while (my_prissy_little_indicator_variable){
> <body>
> }
> isn't satisfying because it doesn't guard the <body> with any
> assurance that the loop invariant will be true before you enter into
> that block of code.
The loop invariant and the exit condition are different things.
The loop invariant is supposed to be true every time the loop
invariant is tested, including on the last iteration, so that
when the loop exits, you can assert that the loop invariant
*and* the exit condition are both true. The trick is to choose
them so that together they ensure whatever it is the loop is
meant to accomplish.
If the exit test is half way through the loop, then the loop
invariant doesn't have to be true before the loop is entered --
it only has to be true by the time the exit test is encountered
for the first time. In other words, the first execution of the
part of the loop before the exit test is really part of the
initialization, and has to be treated as such in the analysis.
> I don't mind while(true) for the case of "do forever" like those
> launcher requirements Peter Billam wrote about up above in this
> thread. It essentially says the loop invariant is that the system
> hasn't crashed yet.
I think it's more accurate to say that, because there is no exit
test, there is no point in the loop at which a loop invariant
has to be true, so there is no need for a loop invariant, at least
in the sense the term is used in the formal theory of correctness
proofs for loops.
It may be desirable to impose invariants on the state of the
system at various points in the loop for other reasons, although
those might better be described as parts of the contracts between
the loop and the functions it calls.
(BTW, "the system hasn't crashed yet" can't be the loop invariant,
because if the loop ever exits then it means the system must have
crashed, so the loop invariant is no longer true!)
--
Greg
greg
> while not done:
> ...
> if n==1: done = True
> ...
Seems to me that 'while not done:' is no better than
'while True:', because in both cases you have to look
inside the loop to find out what the exit condition
is.
Using a more meaningful name for the flag can help,
but you can't teach someone that just by giving them
an overly simplified rules such as "never use
while True:". They'll probably just replace it with
'while not done:' and think they've improved things,
without ever really understanding the issue.
--
Greg
greg
> I'm coaching a group of biologists on basic Python scripting. One
> of my charges mentioned that he had come across the advice never
> to use loops beginning with "while True".
It's possible this is something he was told in relation to
another language that has more options.
For example, in C there's for(;;) as an alternative, although
there's not much to choose between them. Also you can often
use an assignment-as-condition trick to squeeze a loop-and-
a-half into a while(), and you have do-while loops for
testing at the end.
Python is much more limited -- anything which isn't a
for has to be a while of some shape, so it's harder to
avoid while True without introducing extra complexities
into the code.
--
Greg
Luis Zarrabeitia
> In this situation, the middle exit works best -- using
> non-optimal Python
>
> while True:
> lin = file_object.readline()
> if not lin: break
> do something with lin
Actually, in python, this works even better:
for lin in iter(file_object.readline, ""):
... do something with lin
--
Luis Zarrabeitia (aka Kyrie)
Fac. de Matemática y Computación, UH.
http://profesores.matcom.uh.cu/~kyrie
Grant Edwards
>> my_prissy_little_indicator_variable = true
>> while (my_prissy_little_indicator_variable){
>> <body>
>> }
>> isn't satisfying because it doesn't guard the <body> with any
>> assurance that the loop invariant will be true before you enter into
>> that block of code.
>
> I think you meant the other way; the above is the simplest loop case, with
> the test at the start.
Except the test at the start is meaningless when it comes to
reading the code and troubleshooting. What counts are
assignments to my_prissy_little_indicator_variable inside the
loop. And those aren't really any easier to spot that "break"
statements.
--
Grant Edwards grante Yow! I want to read my new
at poem about pork brains and
visi.com outer space ...
Mel
> On Sunday 11 October 2009 11:56:55 pm Dennis Lee Bieber wrote:
>> In this situation, the middle exit works best -- using
>> non-optimal Python
>>
>> while True:
>> lin = file_object.readline()
>> if not lin: break
>> do something with lin
>
> Actually, in python, this works even better:
>
> for lin in iter(file_object.readline, ""):
> ... do something with lin
And one can do this oneself. Faced with
while True:
stuff_required_to_make_the_decision()
if the_decision():
break
other_stuff()
Wrapping the `stuff_required_...` and `the_decision` up into a generator
would simplify the statement, and if it were done well the code overall
would probably be better.
Mel.
Luis Zarrabeitia
> On Mon, Oct 12, 2009 at 11:32 PM, Luis Zarrabeitia <ky...@uh.cu> wrote:
> > Actually, in python, this works even better:
> >
> > for lin in iter(file_object.readline, ""):
> > ... do something with lin
>
>
> >>> with open(path_string) as f:
> >>> for line in f:
> >>> # do something
Gah.
You are right, of course!
Even my for should've been:
for lin in file_object:
...
and nothing more.
I use that iter "trick" only when I don't want the buffering (like, when I'm
reading from stdin in a squid authenticator helper).
I guess that the 'for line in f' is so... natural for me, that the only reason
I could think for writing "while True" for a file iteration was when I needed
to use readline explicitly.
But yes, "with"!
Mensanator
You're missing the point. It's not that you have to
look inside for the terminating condition. It's that
you don't need a break.
>
> --
> Greg
John Reid
Nothing wrong with a having a break IMHO.
while not done:
seems very dangerous to me as you'd have to
del done
before writing the same construct again. That's the sort of thing that
leads to errors.
Ethan Furman
What's wrong with breaks?
I'll agree that they can be overused and abused, but I am not aware of
*any* programming costruct that cannot be. If you rule out one way of
doing things for every situation you can end up making messes just as
bad as the ones you're trying to avoid.
Good programming, as all good endeavors, requires thinking too.
~Ethan~
Mensanator
> Mensanator wrote:
> > On Oct 12, 3:36 am, greg <g...@cosc.canterbury.ac.nz> wrote:
> >> Mensanator wrote:
> >>> while not done:
> >>> ...
> >>> if n==1: done = True
> >>> ...
> >> Seems to me that 'while not done:' is no better than
> >> 'while True:', because in both cases you have to look
> >> inside the loop to find out what the exit condition
> >> is.
>
> >> Using a more meaningful name for the flag can help,
> >> but you can't teach someone that just by giving them
> >> an overly simplified rules such as "never use
> >> while True:". They'll probably just replace it with
> >> 'while not done:' and think they've improved things,
> >> without ever really understanding the issue.
>
> > You're missing the point. It's not that you have to
> > look inside for the terminating condition. It's that
> > you don't need a break.
>
> Nothing wrong with a having a break IMHO.
My opinion is that there is everything wrong with
having a break. I don't think I have ever used one,
I write code that doesn't depend on that crutch.
>
> while not done:
>
> seems very dangerous to me as you'd have to
>
> del done
>
> before writing the same construct again. That's the sort of thing that
> leads to errors.
Duh. I won't write silly code like that either.
If I need more than one loop structure then I'll
do something like
while not done_with_this
while not done_with_that
Besides, since I _always_ initialize the flag
before entering a loop, the flag can be reused
and doesn't have to be deleted (as long as the
loops aren't nested). And since I don't use goto,
there's no chance the initialization can be avoided.
The best way to avoid the pitfalls of spaghetti
code is to not write it in the first place.
Falcolas
How do you manage code where you need to drop out of a neatly written
for or while loop early? I don't use break frequently, but just like
gotos, it does have it's place in well written code.
Glad to hear, by the way, that you don't use gotos in Python. =D
Garrick
Mensanator
I don't. If I thought there would ever be a case when
a for loop had to exit early, I wouldn't use a for loop.
Similarly, if I ever felt the need to escape from a
while loop, I would rewrite it to avoid that situation.
> I don't use break frequently, but just like
> gotos, it does have it's place in well written code.
>
> Glad to hear, by the way, that you don't use gotos in Python. =D
Python doesn't have goto? Gee, I guess I never looked for
one. Learned my lesson from Pascal, eh?
>
> Garrick
David C Ullrich
> I'm coaching a group of biologists on basic Python scripting. One
> of my charges mentioned that he had come across the advice never
> way to start an infinite loop,
Heh-heh: When I read this it occurred to me that another way to
start an infinite loop would be to make a post here on this topic.
Looking at the thread so far it appears I was right.
> but this seems hardly a sufficient
> reason to avoid the construct altogether, as long as one includes
> an exit that is always reached. (Actually, come to think of it,
> there are many situations in which a bona fide infinite loops
> (typically within a try: block) is the required construct, e.g.
> when implementing an event loop.)
>
> I use "while True"-loops often, and intend to continue doing this
> "while True", but I'm curious to know: how widespread is the
> injunction against such loops? Has it reached the status of "best
> practice"?
>
> TIA!
>
> kynn
Raymond Hettinger
> I use "while True"-loops often, and intend to continue doing this
> "while True", but I'm curious to know: how widespread is the
> injunction against such loops? Has it reached the status of "best
> practice"?
This is the first I've ever heard of such an quasi-injunction.
Like you, I use "while True" often. We use it frequently
in the standard library and have no PEP 8 admonition
against it, nor does pychecker report it as a negative practice.
The use of "while 1" loops has a long history in other langauges
as well.
So, if you hear someone make-up a new "best practice" proscibing
"while True", just smile and continue to write programs as you
have been. You will not be alone. Many excellent programmers
write "while True" whenever it is called for.
Raymond
Paul Rubin
> I use "while True"-loops often, and intend to continue doing this
> "while True", but I'm curious to know: how widespread is the
> injunction against such loops? Has it reached the status of "best
> practice"?
E. W. Dijkstra used to advocate that every loop have exactly one entry
point and exactly one exit point, i.e. no multiple break statements.
This is probably a misstatement, but I believe that the purpose was to
be able to specify a precondition at the loop entrance and a
postcondition at the exit, and be able to verify the conditions more
straightforwardly than if there were multiple exit points. But, that
doesn't specifically seem to speak against "while True:". For
example, Ada has a loop construct where the test and break is in the
middle of the loop.
Steven D'Aprano
>> Nothing wrong with a having a break IMHO.
>
> My opinion is that there is everything wrong with having a break. I
> don't think I have ever used one, I write code that doesn't depend on
> that crutch.
Using break can avoid a lot of complication in loops. There's no need to
force every loop to have a single exit point (or for that matter, for
every function to have a single return). Compare the straightforward
implementation of a simple linear search:
for item in seq:
if cond(item):
print item
break
versus doing it without a break:
found = False
for item in seq:
if not found and cond(item):
print item
or:
found = False
seq = iter(seq)
while not found:
item = seq.next()
found = cond(item)
if found:
print item
The first is obviously correct, and efficient (it stops searching when it
has found a result). The second and third avoid using a break, but at the
cost of complicated, inefficient code which isn't obviously correct. If
you need to post-process item before returning, it's simple to replace
the return with a break.
> The best way to avoid the pitfalls of spaghetti code is to not write it
> in the first place.
break does not necessarily lead to spaghetti code. Avoiding break just
because it is a "goto" is cargo-cult programming -- following the magic
incantations with no understanding of the *reasons* for when gotos should
be used and avoided.
The danger with goto is that it is an *unstructured* jump. break,
continue, return, yield, for, while are all *structured* jumps. They can
be abused, like anything, but they're not inherently dangerous.
--
Steven
John Reid
Mensanator wrote:
>> Nothing wrong with a having a break IMHO.
>
> My opinion is that there is everything wrong with
> having a break. I don't think I have ever used one,
> I write code that doesn't depend on that crutch.
I guess its crutch-iness is in the eye of the beholder. You seem to have
a dogmatic view about this.
>
>> while not done:
>>
>> seems very dangerous to me as you'd have to
>>
>> del done
>>
>> before writing the same construct again. That's the sort of thing that
>> leads to errors.
>
> Duh. I won't write silly code like that either.
> If I need more than one loop structure then I'll
> do something like
>
> while not done_with_this
>
>
> while not done_with_that
This is neither clean or well scoped.
>
> Besides, since I _always_ initialize the flag
> before entering a loop, the flag can be reused
> and doesn't have to be deleted (as long as the
> loops aren't nested). And since I don't use goto,
> there's no chance the initialization can be avoided.
Initialising the flag is just another line of code that has to be
interpreted later. I didn't notice the initialisation in your original post.
>
> The best way to avoid the pitfalls of spaghetti
> code is to not write it in the first place.
>
I agree. With 'break' it is obvious what the code does and there are
fewer lines to write in the first place and comprehend in the second.
Mensanator
> Mensanator wrote:
> >> Nothing wrong with a having a break IMHO.
>
> > My opinion is that there is everything wrong with
> > having a break. I don't think I have ever used one,
> > I write code that doesn't depend on that crutch.
>
> I guess its crutch-iness is in the eye of the beholder. You seem to have
> a dogmatic view about this.
No, it's just that the OP was asking whether
avoiding "while True" is considered Best Practice.
How can you answer such a question without sounding
dogmatic?
>
>
>
>
>
>
>
> >> while not done:
>
> >> seems very dangerous to me as you'd have to
>
> >> del done
>
> >> before writing the same construct again. That's the sort of thing that
> >> leads to errors.
>
> > Duh. I won't write silly code like that either.
> > If I need more than one loop structure then I'll
> > do something like
>
> > � � while not done_with_this
>
> > � � while not done_with_that
>
> This is neither clean or well scoped.
>
>
>
> > Besides, since I _always_ initialize the flag
> > before entering a loop, the flag can be reused
> > and doesn't have to be deleted (as long as the
> > loops aren't nested). And since I don't use goto,
> > there's no chance the initialization can be avoided.
>
> Initialising the flag is just another line of code that has to be
> interpreted later. I didn't notice the initialisation in your original post.
"Just another line that has to be interpreted later"
is a strange comment in the context of "del done".
>
>
>
> > The best way to avoid the pitfalls of spaghetti
> > code is to not write it in the first place.
>
> I agree. With 'break' it is obvious what the code does and there are
> fewer lines to write in the first place and comprehend in the second.
Do you consider Perl golf to be Best Practice?
John Reid
Mensanator wrote:
> No, it's just that the OP was asking whether
> avoiding "while True" is considered Best Practice.
> How can you answer such a question without sounding
> dogmatic?
I was just pointing out your style of programming seems inflexible.
>
> "Just another line that has to be interpreted later"
> is a strange comment in the context of "del done".
Interpreted in the sense that the maintainer of the code interprets it,
not the machine.
Ethan Furman
> On Oct 13, 3:44�am, John Reid <j.r...@mail.cryst.bbk.ac.uk> wrote:
>
>>while not done:
>>
>>seems very dangerous to me as you'd have to
>>
>>del done
>>
>>before writing the same construct again. That's the sort of thing that
>>leads to errors.
>>
>Duh. I won't write silly code like that either.
>If I need more than one loop structure then I'll
>do something like
>
>� � while not done_with_this
>
>� � while not done_with_that
>
>before entering a loop, the flag can be reused
>and doesn't have to be deleted (as long as the
>loops aren't nested). And since I don't use goto,
>there's no chance the initialization can be avoided.
>
>>Initialising the flag is just another line of code that has to be
>>interpreted later. I didn't notice the initialisation in your original post.
>
>
> "Just another line that has to be interpreted later"
> is a strange comment in the context of "del done".
I don't believe John is advocating using it, just pointing out that an
extra line is needed -- whether the extra line is "del loop_control_var"
or "loop_control_var = False", it's still an extra line.
Mind you, I'm not saying you should change the way you program as it
seems to work for you, just that there are other ways to write good
clean programs.
~Ethan~
Mensanator
And I'm not saying John nor the OP should stop
using what works for them. But there are certainly
valid reasons for "don't use while True" to be
on the "Best Practices" list.
After all, how many times hve you put 'break'
in a loop comprehension?
>
> ~Ethan~
Mensanator
> kj wrote:
> > I'm coaching a group of biologists on basic Python scripting. �One
> > of my charges mentioned that he had come across the advice never
> > to use loops beginning with "while True". �Of course, that's one
> > way to start an infinite loop,
>
> Heh-heh: When I read this it occurred to me that another way to
> start an infinite loop would be to make a post here on this topic.
> Looking at the thread so far it appears I was right.
You're not getting away that easy.
What's YOUR opinion of "whilr True"?
Paul Rubin
> And I'm not saying John nor the OP should stop using what works for
> them. But there are certainly valid reasons for "don't use while
> True" to be on the "Best Practices" list.
>
> After all, how many times hve you put 'break' in a loop
> comprehension?
<http://okmij.org/ftp/Streams.html#enumerator-stream>:
Towards the best collection traversal interface
"We present a design of the overall optimal collection traversal
interface, which is based on a left-fold-like combinator with
premature termination. The design has been implemented and tested in
practice."
Steven D'Aprano
> And I'm not saying John nor the OP should stop using what works for
> them. But there are certainly valid reasons for "don't use while True"
> to be on the "Best Practices" list.
"Valid"? Well, maybe. But none of them are convincing to me. The best I
have seen is that loops should have a single entry point and a single
exit point, to make it easier to reason about pre- and post-conditions.
But frankly I'm not convinced that's true -- or at least, multiple exists
shouldn't *necessarily* leader to difficulty in reasoning about the post-
condition.
> After all, how many times hve you put 'break' in a loop comprehension?
What's a loop comprehension?
Do you mean *list* comprehensions? List comps aren't supposed to be a
general purpose replacement for for-loops. They are a deliberately cut-
down version which is easier to read, write and execute than a pure
Python for-loop:
>>> from timeit import Timer
>>> Timer("""L = []
... for i in range(20):
... L.append(2*i-1)
... """, '').repeat()
[9.7169408798217773, 9.4620440006256104, 9.4636049270629883]
>>> Timer('[2*i-1 for i in range(20)]', '').repeat()
[5.6287829875946045, 5.8934588432312012, 5.7950780391693115]
But the consequence of that simplicity and speed is that they're not as
general as a for-loop. This was a design decision. But change the design
and you could have something like this:
[expr for name in seq until cond]
which breaks when cond becomes true.
--
Steven
Rhodri James
> And I'm not saying John nor the OP should stop
> using what works for them. But there are certainly
> valid reasons for "don't use while True" to be
> on the "Best Practices" list.
Unfortunately, some of them seem to be reasons from
my point of view to put "*do* use while True" on the
"Best Practices" list. Some of the constructs you
seem to like ring big alarm bells with me, because
I've found entirely too many bugs hidden by them.
> After all, how many times hve you put 'break'
> in a loop comprehension?
How many times have you written 20-line list
comprehensions? If the answer is more than zero,
what on earth possessed you to think it was a
good idea? :-)
--
Rhodri James *-* Wildebeest Herder to the Masses
Paul Rubin
> But the consequence of that simplicity and speed is that they're not as
> general as a for-loop. This was a design decision. But change the design
> and you could have something like this:
>
> [expr for name in seq until cond]
>
> which breaks when cond becomes true.
from itertools import takewhile
xs = [expr(name) for name in takewhile(lambda s: not cond(s), seq)]
greg
> The best I
> have seen is that loops should have a single entry point and a single
> exit point, to make it easier to reason about pre- and post-conditions.
> But frankly I'm not convinced that's true -- or at least, multiple exists
> shouldn't *necessarily* leader to difficulty in reasoning about the post-
> condition.
It's not all that difficult.
If you have multiple exit conditions tested in different
places, in general each one can have its own associated
loop invariant. Then the postcondition of the loop is
(invariant1 and exitcond1) or (invariant2 and exitcond2) or ...
If that gets you where you want to be, then you're
home and dry.
--
Greg
Mensanator
wrote:
> On Tue, 13 Oct 2009 22:59:04 +0100, Mensanator <mensana...@aol.com> wrote:
> > And I'm not saying John nor the OP should stop
> > using what works for them. But there are certainly
> > valid reasons for "don't use while True" to be
> > on the "Best Practices" list.
>
> Unfortunately, some of them seem to be reasons from
> my point of view to put "*do* use while True" on the
Really? Which ones?
> Some of the constructs you
> seem to like ring big alarm bells with me, because
> I've found entirely too many bugs hidden by them.
For example?
>
> > After all, how many times hve you put 'break'
> > in a loop comprehension?
>
> How many times have you written 20-line list
> comprehensions? �
You mean something like this?
p = [''.join
((c0,c1,c2,c3,c4,c5,c6,c7,c8,c9,c10,c11,c12,c13,c14,c15,c16,c17,c18,c19))
for c0 in a for c1 in a for c2 in a for c3 in a for c4 in a for c5 in
a for c6 in a for c7 in a for c8 in a for c9 in a for c10 in a for c11
in a for c12 in a for c13 in a for c14 in a for c15 in a for c16 in a
for c17 in a for c18 in a for c19 in a if (c1>c0) and (c2>c1) and
(c3>c2) and (c4>c3) and (c5>c4) and (c6>c5) and (c7>c6) and (c8>c7)
and (c9>c8) and (c10>c9) and (c11>c10) and (c12>c11) and (c13>c12) and
(c14>c13) and (c15>c14) and (c16>c15) and (c17>c16) and (c18>c17) and
(c19>c18)]
Actually, I didn't write it, the computer did:
v = ','.join(['c%s' % i for i in r0])
f = ' '.join(['for c%s in a' % i for i in r0])
i = ' and '.join(['(c%s>c%s)' % (j,j-1) for j in r1])
e = ''.join(["p = [''.join((",v,")) ",f," if ",i,"]"])
> If the answer is more than zero,
> what on earth possessed you to think it was a
> good idea? :-)
I didn't. It was a feasibility study. But that was
in the days before itertools was upgraded to handle
all the subsets of the Cartesian Product. No need for
such silliness now. And itertools works better.
TerryP
Marco Mariani
> One thing to note is that "break" ONLY exits the innermost loop --
> Ada adds the confusion that one could define a label on the loops, and
> have the innermost use
> exit outer_label [when condition]
>
>
> THAT I find scary... Since you have to match the label name to
> something that occurs somewhere prior to the "exit", and THEN have to
> find the end of that loop.
But we have exceptions. And I know somebody, in other languages, thinks
it's a Best Practice to avoid using exceptions for flow control.
Thankfully, python programmers are less dogmatic, and use whatever makes
sense to use. I hope.
Tim Rowe
> Dennis Lee Bieber wrote:
>
>> One thing to note is that "break" ONLY exits the innermost loop --
>> Ada adds the confusion that one could define a label on the loops, and
>> have the innermost use
>> exit outer_label [when condition]
>>
>>
>> THAT I find scary... Since you have to match the label name to
>> something that occurs somewhere prior to the "exit", and THEN have to
>> find the end of that loop.
>
> But we have exceptions.
So has Ada.
> And I know somebody, in other languages, thinks it's
> a Best Practice to avoid using exceptions for flow control.
>
> Thankfully, python programmers are less dogmatic, and use whatever makes
> sense to use. I hope.
Absolutely. And it doesn't make sense to use exceptions for flow control :-)
--
Tim Rowe
TerryP
to something like this?
begin_loop:
unless TEST
goto end_loop
;; loop body here
if TEST
goto begin_loop
end_loop:
Which could likely be used to implement something like:
while TEST:
# loop body here
in any highly expressive language; which in of it self displays
something about Computer Science.
or am I just talking out my ass?
I've watched this thread with some interest, but really it sounds to
me like the metrics are getting rather lax and this will probably end
up on par with a for (i=0; i < count; i++) versus for (i=0; i < count;
i--) discussion. By that, I mean:
Fruitful conversation but there is no one spoon for every bowl.
--
TerryP.
Just Another Programmer.
Mensanator
> On Tue, 13 Oct 2009 15:02:09 -0700 (PDT), Mensanator
> <mensana...@aol.com> declaimed the following in
> gmane.comp.python.general:
>
> > You're not getting away that easy.
>
> > What's YOUR opinion of "whilr True"?
>
> upon it's keywords...
Duh. You DO know that 'r' is next to 'e' on the
keyboard?
>
> � � � � If anything -- I'd suggest a proposal to add a plain � �loop � �as a
> keyword in Python, whose effect is equivalent to a "while True", but a
> break � �must be used to exit said loop (well, we'll ignore raising an
> exception <G>)
And what will that accomplish? The problem isn't
using while True, it's the fact that you are
escaping the loop. Best Practice is to EXIT the
loop properly, not escape from it.
> --
> � � � � Wulfraed � � � � Dennis Lee Bieber � � � � � � � KD6MOG
> � � � � wlfr...@ix.netcom.com � � HTTP://wlfraed.home.netcom.com/
MRAB
> On Tue, 13 Oct 2009 15:02:09 -0700 (PDT), Mensanator
> gmane.comp.python.general:
>
>>
>> What's YOUR opinion of "whilr True"?
>>
> upon it's keywords...
>
> keyword in Python, whose effect is equivalent to a "while True", but a
> break must be used to exit said loop (well, we'll ignore raising an
> exception <G>)
<bikeshedding>I'd prefer it to be called "repeat".</bikeshedding>
Tim Rowe
> If anything -- I'd suggest a proposal to add a plain loop as a
> keyword in Python, whose effect is equivalent to a "while True", but a
> break must be used to exit said loop (well, we'll ignore raising an
> exception <G>)
And with enough static analysis to guarantee that the break will be
reached? I think it would be a bit much to expect Python to solve the
halting problem!
--
Tim Rowe
Ethan Furman
> On Oct 14, 2:19�am, Dennis Lee Bieber <wlfr...@ix.netcom.com> wrote:
>
>>On Tue, 13 Oct 2009 15:02:09 -0700 (PDT), Mensanator
>><mensana...@aol.com> declaimed the following in
>>gmane.comp.python.general:
>>
>>
>>>You're not getting away that easy.
>>
>>>What's YOUR opinion of "whilr True"?
>>
>>� � � � Uhm... that it isn't valid in any language having English influence
>>upon it's keywords...
>
>
> Duh. You DO know that 'r' is next to 'e' on the
> keyboard?
Not on mine -- it's next to 'o' and 'u'. :-) Go Dvorak!
>>� � � � If anything -- I'd suggest a proposal to add a plain � �loop � �as a
>>keyword in Python, whose effect is equivalent to a "while True", but a
>>break � �must be used to exit said loop (well, we'll ignore raising an
>>exception <G>)
>
>
> And what will that accomplish? The problem isn't
> using while True, it's the fact that you are
> escaping the loop. Best Practice is to EXIT the
> loop properly, not escape from it.
I don't think anyone's arguing the opposite. What I *am* seeing argued
is if it's the only correct way to do it, and that anyone who does it
any other way is a scoundrel and a knave. ;-)
For what it's worth, most of my loops run to completion, with no sign of
a break anywhere. Some have a break, and use it. Some, even, (dare I
say it?) use break *and* else! And it's awesome! Go Python! :-D
~Ethan~
Jorgen Grahn
...
> I was a bit surprised that nobody in this discussion so far bantered
> around the phrase "loop invariant", but then I looked in
> http://en.wikipedia.org/wiki/Loop_invariant and found it was draped in
> so much formalism that it's sure to put off all but the most dedicated
> of Computer Science fans.
Haven't read it. But much of the CS parts of the Wikipedia sucks, and
whoever writes there doesn't own the trademark on loop invariants
anyway.
IME, a loop invariant is a simple and useful tool for thinking about
the correctness of code. Class invariants (or whatever they are called)
are even better.
> I haven't been in college in 35 years, so
> I'll admit to being rusty on this, but as I remember it, any time we
> wrote a loop, we were expected to be able to say what the loop
> invariant is.
Yes, it's as simple as that.
> my_prissy_little_indicator_variable = true
> while (my_prissy_little_indicator_variable){
> <body>
> }
> isn't satisfying because it doesn't guard the <body> with any
> assurance that the loop invariant will be true before you enter into
> that block of code.
Why not? To me, it obviously does.
It would also help if you didn't use intentionally meaningless and
annoying variable names in your examples. In reality you would have a
meaningful expression like "not inputqueue.empty()" or
"time() < deadline" or something.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Jorgen Grahn
> On 2009-10-12, Gabriel Genellina <gags...@yahoo.com.ar> wrote:
>
>>> my_prissy_little_indicator_variable = true
>>> while (my_prissy_little_indicator_variable){
>>> <body>
>>> }
>>> isn't satisfying because it doesn't guard the <body> with any
>>> assurance that the loop invariant will be true before you enter into
>>> that block of code.
>>
>> the test at the start.
>
> Except the test at the start is meaningless when it comes to
> reading the code and troubleshooting. What counts are
> assignments to my_prissy_little_indicator_variable inside the
> loop. And those aren't really any easier to spot that "break"
> statements.
It's a red herring. A good loop tends to *not* have a boolean
variable as the while ... expression. That smells like flag
programming, and if I cannot come up with anything better that that, I
often prefer a "while 1" with breaks in it.
For a real-life loop, see for example
http://en.wikipedia.org/wiki/Binary_search#Iterative
(except it confuses me because it's a repeat ... until and it's in
Pascal with that quaint 1-based indexing)
Jorgen Grahn
> Dennis Lee Bieber wrote:
>
>> One thing to note is that "break" ONLY exits the innermost loop --
>> Ada adds the confusion that one could define a label on the loops, and
>> have the innermost use
>> exit outer_label [when condition]
>>
>>
>> THAT I find scary... Since you have to match the label name to
>> something that occurs somewhere prior to the "exit", and THEN have to
>> find the end of that loop.
>
> But we have exceptions. And I know somebody, in other languages, thinks
> it's a Best Practice to avoid using exceptions for flow control.
A lot of C++ programmers think so, and Stroustrup himself says
"exceptions are for exceptional things" or something to that effect.
Is that what you're thinking of?
Thankfully, Stroustrup doesn't use the dreaded phrase "Best Practice",
which as far as I can tell is designed to shut down rational thought
in the audience.
> Thankfully, python programmers are less dogmatic, and use whatever makes
> sense to use. I hope.
Calling it "dogmatic" is unfair. C++ is very different from Python,
and has a different implementation of exceptions. You also tend to use
the language to solve a different set of problems.
That said, I still don't fully understand the rationale behind that
advice or rule ... so I'm willing to break it, and sometimes I do.
Raymond Hettinger
> it's a Best Practice to avoid using exceptions for flow control.
Ah, now we have two code prions in just one thread.
I hope no newbie or supervisor reads this thread and latches
on to those two counter-productive ideas.
ISTM, both ideas are dangerous contagious because they are
true in some limited contexts but useless (and harmful)
when applied to programming in general.
IIRC, the C++ admonition against using exceptions for flow control
was rooted in performance concerns specific to that language and
its compilers. It was not stylistic advice and did not deny that
flow control exceptions could provide elegant solutions to some
programming challenges.
Python's IndexError and KeyError are all about flow control.
The notion is deeply embedded in the language and it would
be a disservice to advise people to not use the language as
designed.
Likewise, the use of "while True" tends to be more important
in Python than in other languages because we can't combine
assignment with a conditional as we can in C. So instead,
we have this idiom:
while True:
s = f.read(blocksize)
if not s:
break
...
Suggested further reading for those who are interested:
"The Little MLer" -- a chunk of this book is devoted to showing
how exceptions can simplify code that would otherwise be
somewhat awkward to express (the remainder of the book is devoted
to thinking about types and how to compose program components).
"Structured Programming with go to Statements" by Donald Knuth
has an in-depth comparative analysis of many different looping
constructs.
Raymond
Paul Rubin
> IIRC, the C++ admonition against using exceptions for flow control
> was rooted in performance concerns specific to that language and
> its compilers. It was not stylistic advice and did not deny that
> flow control exceptions could provide elegant solutions to some
> programming challenges.
I've been wondering about that. I know that Java exceptions are
ridiculously expensive but I didn't realize it was so bad with C++.
> Python's IndexError and KeyError are all about flow control.
> The notion is deeply embedded in the language and it would
> be a disservice to advise people to not use the language as
> designed.
Well, usually they're wrapped in iterators etc.
> So instead, we have this idiom:
>
> while True:
> s = f.read(blocksize)
> if not s:
> break
> ...
Well,
while iter(lambda: f.read(blocksize), ''):
evolved because of the awkwardness of that idiom...
> "The Little MLer" -- a chunk of this book is devoted to showing
> how exceptions can simplify code that would otherwise be
> somewhat awkward to express (the remainder of the book is devoted
> to thinking about types and how to compose program components).
Interesting--I've been wanting to look at that book. I wonder whether
its uses of exceptions could mostly be better handled with coroutines.
> "Structured Programming with go to Statements" by Donald Knuth
> has an in-depth comparative analysis of many different looping
> constructs.
Found some pdf's:
http://scholar.google.com/scholar?cluster=17368311454828547380
Keep in mind that the article is 35 years old though, and is purely
imperative. Lots of stuff done with cockamamie looping constructs is
more cleanly done with Python generators, itertools, higher-order
functions, etc.
Jack Norton
>
> I'm coaching a group of biologists on basic Python scripting. One
> of my charges mentioned that he had come across the advice never
> to use loops beginning with "while True". Of course, that's one
> reason to avoid the construct altogether, as long as one includes
> an exit that is always reached. (Actually, come to think of it,
> there are many situations in which a bona fide infinite loops
> (typically within a try: block) is the required construct, e.g.
> when implementing an event loop.)
>
> I use "while True"-loops often, and intend to continue doing this
> "while True", but I'm curious to know: how widespread is the
> injunction against such loops? Has it reached the status of "best
> practice"?
>
> TIA!
>
> kynn
>
and dogma alike. I'd like to add a personal use of `while True:` that
has nothing to do with either best practices or dogma.
I use python a *lot* to do day-to-day tasks in an engineering lab. I
use it to control, log, or otherwise converse with rs232 based gear, as
well as use it to back up or organize documents, etc... (lo and behold,
I use this scripting language to write little scripts here and there).
Don't get me wrong, I also write full blown control/logging apps with
python, but that is only 10% of my usage.
Whenever I need to quickly log something (serial output of a device)
quickly, I find myself writing this in the python REPL:
import serial
comport = serial.Serial('COMx', timeout=1)
while True:
get = comport.readline()
f.open("blah", 'a')
f.write(get)
f.close()
It is short enough that I don't see the need to write my own module.
Sometimes I even add a little regexp based filtering -- which adds 2
lines total. When I am done logging I just give 'er a CTRL-C and be
done with it. It is also a hell of a lot less buggy and error prone
than hyperterminal, which my boss uses to do the same thing.
I think this is a perfect example of `while True:` that works damn well,
and there isn't anything that can replace its simplicity. Programming
practices be damned, it is invaluable, and I would recommend doing it in
my situation to any person, regardless of programming experience.
Food for thought.
-Jack
Tim Rowe
> I was a bit surprised that nobody in this discussion so far bantered
> around the phrase "loop invariant", but then I looked in
> http://en.wikipedia.org/wiki/Loop_invariant and found it was draped in
> so much formalism that it's sure to put off all but the most dedicated
> of Computer Science fans.
I think in this case the loop variant is more use than the loop variant.
Basically, the loop variant is what is true on every pass of the loop.
If you're being formal, you have to show that it's true on entry to
the loop and remains true on every pass of the loop. That means that
on exit from the loop you can guarantee the loop invariant and the
exit condition.
The loop variant is a finite natural number (positive or zero integer)
that is guaranteed to decrease on every pass of the loop. Because a
finite natural number cannot decrease indefinitely, if you can define
a loop variant then you gurantee that the loop will terminate.
Even if you are not being formal, just considering what the loop
variants and invariants can save no end of trouble with tricky loops.
--
Tim Rowe
Rhodri James
> On Oct 13, 5:38�pm, "Rhodri James" <rho...@wildebst.demon.co.uk>
> wrote:
>> On Tue, 13 Oct 2009 22:59:04 +0100, Mensanator <mensana...@aol.com>
>> wrote:
>> > And I'm not saying John nor the OP should stop
>> > using what works for them. But there are certainly
>> > valid reasons for "don't use while True" to be
>> > on the "Best Practices" list.
>>
>> Unfortunately, some of them seem to be reasons from
>> my point of view to put "*do* use while True" on the
>> "Best Practices" list. �
>
> Really? Which ones?
>
>> Some of the constructs you
>> seem to like ring big alarm bells with me, because
>> I've found entirely too many bugs hidden by them.
>
> For example?
Well, this one's always popular:
done = False
while not done:
do_stuff()
done = worry_about_stuff()
do_more_stuff_at_great_length()
done = worry_about_more_stuff()
and_so_on()
Steven D'Aprano
> On Oct 14, 2:19�am, Dennis Lee Bieber <wlfr...@ix.netcom.com> wrote:
>> On Tue, 13 Oct 2009 15:02:09 -0700 (PDT), Mensanator
>> <mensana...@aol.com> declaimed the following in
>> gmane.comp.python.general:
>>
>> > You're not getting away that easy.
>>
>> > What's YOUR opinion of "whilr True"?
>>
>> Uhm... that it isn't valid in any language having English
>> influence upon it's keywords...
>
> Duh. You DO know that 'r' is next to 'e' on the keyboard?
Only on QWERTY keyboards. Not on Dvorak keyboards.
Do you know how to proof-read your writing before hitting send? If not,
please learn. A spell checker may help. If you do know how, if you care
so little for what you write that you can't be bothered, why should
anyone care enough to read what you write? Either way, there's no call
for you to be snarky when people call you on stupid typos. Your mistake
could happen to anyone, but it was still *your* mistake.
[...]
> And what will that accomplish? The problem isn't using while True, it's
> the fact that you are escaping the loop.
That's not a problem.
> Best Practice is to EXIT the loop properly, not escape from it.
A break does exit the loop properly. That's what it is for, it would be a
pretty stupid language that had break exit the loop improperly.
Nobody is forcing you to use break. You can write Pascal in any language
you like.
--
Steven
Steven D'Aprano
That's a stupid objection. Python doesn't guarantee that any of the
following will halt:
for x in iterator:
pass
while flag:
pass
for x in [1, 10, 20, 10**100]:
time.sleep(x)
(Technically, that last one will eventually halt, if you're prepared to
wait long enough... about a billion trillion trillion trillion trillion
trillion trillion trillion years.)
Why should Python make that guarantee about this hypothetical "loop
forever" construct?
--
Steven
Steven D'Aprano
>> But we have exceptions. And I know somebody, in other languages, thinks
>> it's a Best Practice to avoid using exceptions for flow control.
>
> A lot of C++ programmers think so, and Stroustrup himself says
> "exceptions are for exceptional things" or something to that effect. Is
> that what you're thinking of?
>
> Thankfully, Stroustrup doesn't use the dreaded phrase "Best Practice",
> which as far as I can tell is designed to shut down rational thought in
> the audience.
>
>> Thankfully, python programmers are less dogmatic, and use whatever
>> makes sense to use. I hope.
>
> Calling it "dogmatic" is unfair. C++ is very different from Python, and
> has a different implementation of exceptions. You also tend to use the
> language to solve a different set of problems.
>
> That said, I still don't fully understand the rationale behind that
> advice or rule ... so I'm willing to break it, and sometimes I do.
Setting up a try...except block is cheap in Python. According to my
tests, the overhead is little more than that of a single pass statement.
But actually raising and catching the exception is not cheap. If you use
a lot of exceptions for flow control, performance will probably suffer.
In C++, exceptions are expensive, whether you catch one or not.
Also, using exceptions this way is a structured form of GOTO -- it's easy
to abuse and turn it into spaghetti code. Actually, not that easy to
abuse, because you can't jump back into the try block. It's more like a
multi-level break outside of a loop than a general GOTO.
--
Steven
Paul Rubin
> Why should Python make that guarantee about this hypothetical "loop
> forever" construct?
It doesn't make much sense for Python as normally practiced.
Termination proofs (aka proofs of progress) are used in formal
verification systems to make sure that the verification logic is
consistent and that type-level inferences are valid. They generally
have very little to do with making sure that the program's actual
running time is bounded by anything reasonable. In fact infinite
loops are permitted in some such systems, but only on infinite data
streams (e.g. the request stream of a web server).
http://en.wikipedia.org/wiki/Total_functional_programming
cites a pretty accessible paper by D. Turner that explains the
idea in more detail.
Mensanator
cybersource.com.au> wrote:
> On Wed, 14 Oct 2009 09:34:28 -0700, Mensanator wrote:
> > On Oct 14, 2:19 am, Dennis Lee Bieber <wlfr...@ix.netcom.com> wrote:
> >> On Tue, 13 Oct 2009 15:02:09 -0700 (PDT), Mensanator
> >> <mensana...@aol.com> declaimed the following in
> >> gmane.comp.python.general:
>
> >> > You're not getting away that easy.
>
> >> > What's YOUR opinion of "whilr True"?
>
> >> � � � �Uhm... that it isn't valid in any language having English
> >> influence upon it's keywords...
>
> > Duh. You DO know that 'r' is next to 'e' on the keyboard?
>
> Only on QWERTY keyboards. Not on Dvorak keyboards.
Does anyone actually use those things?
>
> Do you know how to proof-read your writing before hitting send?
Yeah. And I missed it. Maybe because my laptop has a few
broken columns of pixels.
> If not,
> please learn. A spell checker may help.
Not with Google.
> If you do know how, if you care
> so little for what you write that you can't be bothered, why should
> anyone care enough to read what you write?
Conclusion based on false premise.
> Either way, there's no call
> for you to be snarky when people call you on stupid typos.
I suppose this wasn't snarky:
> >> Uhm... that it isn't valid in any language having English
> >> influence upon it's keywords...
> Your mistake
> could happen to anyone, but it was still *your* mistake.
No, it wasn't. You should learn the difference between
an error and a mistake. There's nothing to be learned from
pointing out a typo. Whereas a mistake, such as using
"their" in place of "there" should be pointed out so
as to prevent future occurences.
>
> [...]
>
> > And what will that accomplish? The problem isn't using while True, it's
> > the fact that you are escaping the loop.
>
> That's not a problem.
It can be.
>
> > Best Practice is to EXIT the loop properly, not escape from it.
>
> A break does exit the loop properly. That's what it is for, it would be a
> pretty stupid language that had break exit the loop improperly.
>
> Nobody is forcing you to use break.
And no one is forcing the OP to stop using "while True"
even if it is not considered Best Practice.
> You can write Pascal in any language you like.
My experience with Pascal is it tended to produce
bullet-proof code. The lessons learned from Pascal
can only make my Python programs better.
> > --
> Steven
Mensanator
> Mensanator wrote:
> > On Oct 14, 2:19 am, Dennis Lee Bieber <wlfr...@ix.netcom.com> wrote:
>
> >>On Tue, 13 Oct 2009 15:02:09 -0700 (PDT), Mensanator
> >><mensana...@aol.com> declaimed the following in
> >>gmane.comp.python.general:
>
> >>>You're not getting away that easy.
>
> >>>What's YOUR opinion of "whilr True"?
>
> >> Uhm... that it isn't valid in any language having English influence
> >>upon it's keywords...
>
> > Duh. You DO know that 'r' is next to 'e' on the
> > keyboard?
>
> Not on mine -- it's next to 'o' and 'u'. �:-) �Go Dvorak!
Does that mean you think "whilr" is a word?
>
> >> If anything -- I'd suggest a proposal to add a plain loop as a
> >>keyword in Python, whose effect is equivalent to a "while True", but a
> >>break must be used to exit said loop (well, we'll ignore raising an
> >>exception <G>)
>
> > And what will that accomplish? The problem isn't
> > using while True, it's the fact that you are
> > escaping the loop. Best Practice is to EXIT the
> > loop properly, not escape from it.
>
> I don't think anyone's arguing the opposite. �
I get the impression many people are, in fact,
arguing the opposite.
> What I *am* seeing argued
> is if it's the only correct way to do it, and that anyone who does it
> any other way is a scoundrel and a knave. �;-)
First of all, _I_ didn't bring up the concept of Best Practice,
nor have I insisted Best Practice means there is only one
correct way to do something. I interpret it as meaning there
may be many correct ways to do something, but of those,
this is the best way, barring special circumstances.
>
> For what it's worth, most of my loops run to completion, with no sign of
> a break anywhere. �Some have a break, and use it. �Some, even, (dare I
> say it?) use break *and* else! �
Breaks can be used properly, but it's easy to use them
improperly. How many of your loops start "while True"?
Tim Rowe
> IMHO, break, goto, etc. have their place, but they're ripe for abuse which
> leads to spaghetti code.
Unrestricted goto can leat to spaghetti code, but surely break can't?
AFAICS, any break construct will still be H-K reducible.
--
Tim Rowe
Tim Rowe
>> And with enough static analysis to guarantee that the break will be
>> reached? I think it would be a bit much to expect Python to solve the
>> halting problem!
Not to what I thought was being proposed -- it seemed to make the
break mandatory, not merely the only clean way to exit.
--
Tim Rowe
Tim Rowe
> Setting up a try...except block is cheap in Python. According to my
> tests, the overhead is little more than that of a single pass statement.
>
> But actually raising and catching the exception is not cheap. If you use
> a lot of exceptions for flow control, performance will probably suffer.
>
> In C++, exceptions are expensive, whether you catch one or not.
>
> Also, using exceptions this way is a structured form of GOTO -- it's easy
> to abuse and turn it into spaghetti code. Actually, not that easy to
> abuse, because you can't jump back into the try block. It's more like a
> multi-level break outside of a loop than a general GOTO.
I don't think it's *only* the performance thing, it's also clarity.
The understood meaning of throwing an exception is to say "something
happened that shouldn't have". If one uses it when something has
happened that *should* have, because it happens to have the right
behaviour (even if the overhead doesn't matter), then one is
misrepresenting the program logic.
--
Tim Rowe
Aahz
Tim Rowe <dig...@gmail.com> wrote:
>
>The understood meaning of throwing an exception is to say "something
>happened that shouldn't have". If one uses it when something has
>happened that *should* have, because it happens to have the right
>behaviour (even if the overhead doesn't matter), then one is
>misrepresenting the program logic.
Except, of course, that your "understood meaning" is wrong for Python.
Perhaps you should go look up StopIteration.
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
"To me vi is Zen. To use vi is to practice zen. Every command is a
koan. Profound to the user, unintelligible to the uninitiated. You
discover truth everytime you use it." --re...@lion.austin.ibm.com
Bearophile
> http://scholar.google.com/scholar?cluster=17368311454828547380
>
> Keep in mind that the article is 35 years old though, and is purely
> imperative. Lots of stuff done with cockamamie looping constructs is
> more cleanly done with Python generators, itertools, higher-order
> functions, etc.
That's a famous and very good paper, a good read for people that like
to program.
The Example1 and Example2 can be rewritten in several different ways,
but several compilers today are not able to perform such optimizations
yet, so what Knuth has written there are still among the faster ways
to implement that algorithm.
Bye,
bearophile
Russ P.
> I'm coaching a group of biologists on basic Python scripting. One
> of my charges mentioned that he had come across the advice never
> to use loops beginning with "while True". Of course, that's one
> way to start an infinite loop, but this seems hardly a sufficient
> reason to avoid the construct altogether, as long as one includes
> an exit that is always reached. (Actually, come to think of it,
> there are many situations in which a bona fide infinite loops
> (typically within a try: block) is the required construct, e.g.
> when implementing an event loop.)
>
> I use "while True"-loops often, and intend to continue doing this
> "while True", but I'm curious to know: how widespread is the
> injunction against such loops? Has it reached the status of "best
> practice"?
Never, ever use "while True". It's an abomination. The correct form is
"while 1".
But seriously, folks ... "while condition" is nice when the desired
break is at the beginning or end of the block, but otherwise it forces
unnecessary contortions that can hamper readability.
Steven D'Aprano
>> Also, using exceptions this way is a structured form of GOTO -- it's
>> easy to abuse and turn it into spaghetti code. Actually, not that easy
>> to abuse, because you can't jump back into the try block. It's more
>> like a multi-level break outside of a loop than a general GOTO.
>
> I don't think it's *only* the performance thing, it's also clarity. The
> understood meaning of throwing an exception is to say "something
> happened that shouldn't have". If one uses it when something has
> happened that *should* have, because it happens to have the right
> behaviour (even if the overhead doesn't matter), then one is
> misrepresenting the program logic.
No, you have a fundamental misunderstanding. They're called exceptions,
not errors, because they represent exceptional cases. Often errors are
exceptional cases, but they're not the only sort of exceptional case.
Python uses exceptions for flow control: e.g. for-loops swallow
StopIteration or IndexError to indicate the end of the loop. In the
context of a for-loop, StopIteration or IndexError doesn't represent an
error. It doesn't represent an unexpected case. It represents an
expected, but exceptional (special) case: we expect that most sequences
are finite, and it is normal to eventually reach the end of the sequence,
after which the loop must change behaviour.
Similarly, it's hardly an *error* for [1, 2, 3].index(5) to fail -- who
is to say that the list is supposed to have 5 in it? ValueError (a
slightly misleading name in this situation) is used to indicate an
exceptional, but not unexpected, occurrence.
Likewise, KeyboardInterrupt is used to allow the user to halt processing;
SystemExit is used to shut down the Python virtual machine; and warnings
are implemented using exceptions. There may be others among the built-ins
and standard library, but even if there aren't, there is plenty of
precedence for us to do the same.
--
Steven
Tim Rowe
> No, you have a fundamental misunderstanding. They're called exceptions,
> not errors, because they represent exceptional cases. Often errors are
> exceptional cases, but they're not the only sort of exceptional case.
The whole reason for the mechanism, across all languages that have it,
is to deal with situations that you don't know how to deal with
locally. That's why they have the overhead that they do.
> Python uses exceptions for flow control:
Yes, and in some cases I think that's a serious language wart. Not
enough to put me off the language, but a serious wart nevertheless.
> Similarly, it's hardly an *error* for [1, 2, 3].index(5) to fail -- who
> is to say that the list is supposed to have 5 in it? ValueError (a
> slightly misleading name in this situation) is used to indicate an
> exceptional, but not unexpected, occurrence.
That one is, I think, a legitimate use of an exception. The result
returned by index is defined if the index is in bounds. If not, index
doesn't know whether it was supposed to be in bounds or not, and so
can't handle the case locally. It could suggest an error or merely
(IMHO) poor programming. Because index cannot know what the proper
action is, an exception is the appropriate response.
> Likewise, KeyboardInterrupt is used to allow the user to halt processing;
> SystemExit is used to shut down the Python virtual machine; and warnings
> are implemented using exceptions.
Again, I think it's fair to treat a program being killed from outside
as an exception as far as the program is concerned. They're not things
the program has brought about, and the original handling code has no
way of knowinng what response is appropriate. Same with warnings; they
*probably* shouldn't happen but only the application programmer can
know whether they should or not.
The point is that an exception causes a change in program flow, so of
course they're used for flow control. It's what they do. The question
is in what cases it's appropriate to use them.
--
Tim Rowe
Aahz
Tim Rowe <dig...@gmail.com> wrote:
>
>The point is that an exception causes a change in program flow, so of
>course they're used for flow control. It's what they do. The question
>is in what cases it's appropriate to use them.
Standard Python idiom:
try:
d[key] += value
except KeyError:
d[key] = value
Maybe you need to re-think "appropriate".
Paul Rubin
> Standard Python idiom:
>
> try:
> d[key] += value
> except KeyError:
> d[key] = value
>
> Maybe you need to re-think "appropriate".
But more recent style prefers:
d = collections.defaultdict(int)
...
d[key] += value
Aahz
That was a trivial example; non-trivial examples not addressed by
defaultdict are left as an exercise for the reader.
Paul Rubin
> > d = collections.defaultdict(int)
> > ...
> > d[key] += value
>
> That was a trivial example; non-trivial examples not addressed by
> defaultdict are left as an exercise for the reader.
Even in the "nontrivial" examples, I think avoiding the exception is
stylistically preferable:
d[key] = value + d.get(key, 0)
It might be worth handling the exception in an inner loop where you
want to avoid the cost of looking up key in the dictionary twice, but
even that requires profiling to be sure.
Terry Reedy
Yes, the motivation was to reduce 4 lines to 1 line for a common use
case, and not because of any sense of 'inappropriateness'.
tjr
Terry Reedy
Nicely put. Programmers are exceptional people, but not erroneous, in
spite of nerd stereotypes ;-).
tjr
Paul Rubin
> > d[key] += value
>
> Yes, the motivation was to reduce 4 lines to 1 line for a common use
> case, and not because of any sense of 'inappropriateness'.
Reducing 4 confusing lines to 1 clear one is almost always appropriate.
Steven D'Aprano
This is true, but there is nothing confusing about "Asking for
forgiveness is better than asking for permission".
For the record, the four lines Paul implies are "confusing" are:
try:
d[key] += value
except KeyError:
d[key] = value
Paul, if that confuses you, perhaps you should consider a change of
career. *wink*
On the other hand:
d = collections.defaultdict(int)
d[key] += value
is confusing, at least to me. I would expect the argument to defaultdict
to be the value used as a default, not a callable. In other words, I
would expect the above to try adding the type `int` to the integer
`value` and fail, and wonder why it wasn't written as:
d = collections.defaultdict(0)
d[key] += value
Having thought about it, I can see why defaultdict is done that way,
instead of this:
class MyDefaultDict(dict):
def __init__(self, default=None):
self._default = default
def __getitem__(self, key):
if key in self:
return self[key]
else:
return self._default
And here's why this doesn't work too well:
>>> d = MyDefaultDict([])
>>> d['a'] = [1,2]
>>> d['b'] = [3,4,5]
>>> d
{'a': [1, 2], 'b': [3, 4, 5]}
>>> d['c'] += [6,7]
>>> d
{'a': [1, 2], 'c': [6, 7], 'b': [3, 4, 5]}
So far so good. But wait:
>>> d['d'] += [8]
>>> d
{'a': [1, 2], 'c': [6, 7, 8], 'b': [3, 4, 5], 'd': [6, 7, 8]}
Oops. So even though it's initially surprising and even confusing, the
API for collections.defaultdict functionally more useful.
--
Steven
Paul Rubin
>
> try:
> d[key] += value
> except KeyError:
> d[key] = value
Consider what happens if the computation of "key" or "value" itself
raises KeyError.
Hendrik van Rooyen
> In article <mailman.1589.1255781...@python.org>,
>
> Tim Rowe <dig...@gmail.com> wrote:
> >The point is that an exception causes a change in program flow, so of
> >course they're used for flow control. It's what they do. The question
> >is in what cases it's appropriate to use them.
>
> Standard Python idiom:
>
> try:
> d[key] += value
> except KeyError:
> d[key] = value
>
> Maybe you need to re-think "appropriate".
Standard Python idiom:
if key in d:
d[key] += value
else:
d[key] = value
Maybe you need to re-think "appropriate".
- Hendrik
Steven D'Aprano
How does using a defaultdict for d save you from that problem?
table = {101: 'x', 202: 'y'}
data = {'a': 1, 'b': 2}
d = collections.defaultdict(int)
d[table[303]] += data['c']
It may not be appropriate to turn table and data into defaultdicts --
there may not be a legitimate default you can use, and the key-lookup
failure may be a fatal error. So defaultdict doesn't solve your problem.
If you need to distinguish between multiple expressions that could raise
exceptions, you can't use a single try to wrap them all. If you need to
make that distinction, then the following is no good:
try:
key = keytable[s]
value = datatable[t]
d[key] += value
except KeyError:
print "An exception occurred somewhere"
But if you need to treat all three possible KeyErrors identically, then
the above is a perfectly good solution.
--
Steven
Lie Ryan
Isn't key and value just a simple variables/names? Why should it ever
raises KeyError? The only other error that try-block code could ever
possibly throw are NameError and possibly MemoryError.
Paul Rubin
> Standard Python idiom:
>
> if key in d:
> d[key] += value
> else:
> d[key] = value
The issue is that uses two lookups. If that's ok, the more usual idiom is:
Ben Finney
> Paul Rubin wrote:
> > Steven D'Aprano <st...@REMOVE-THIS-cybersource.com.au> writes:
> >> For the record, the four lines Paul implies are "confusing" are:
> >>
> >> try:
> >> d[key] += value
> >> except KeyError:
> >> d[key] = value
> >
> > Consider what happens if the computation of "key" or "value" itself
> > raises KeyError.
>
> Isn't key and value just a simple variables/names?
In that example, yes. Paul is encouraging the reader to think of more
complex cases where they are compound expressions, that can therefore
raise other errors depending on what those expressions contain.
--
\ “Don't be afraid of missing opportunities. Behind every failure |
`\ is an opportunity somebody wishes they had missed.” —Jane |
_o__) Wagner, via Lily Tomlin |
Ben Finney
Steven D'Aprano
> 2009/10/17 Steven D'Aprano <st...@remove-this-cybersource.com.au>:
>
>> No, you have a fundamental misunderstanding. They're called exceptions,
>> not errors, because they represent exceptional cases. Often errors are
>> exceptional cases, but they're not the only sort of exceptional case.
>
> The whole reason for the mechanism, across all languages that have it,
> is to deal with situations that you don't know how to deal with locally.
That confuses me. If I call:
y = mydict[x]
how does my knowledge of what to do if x is not a key relate to whether
the language raises an exception, returns an error code, dumps core, or
prints "He's not the Messiah, he's a very naughty boy" to stderr?
You seem to be making a distinction of *intent* which, as far as I can
tell, doesn't actually exist. What's the difference in intent between
these?
y = mydict[x]
if y == KeyErrorCode:
handle_error_condition()
process(y)
and this?
try:
y = mydict[x]
except KeyError:
handle_error_condition()
process(y)
Neither assumes more or less knowledge of what to do in
handle_error_condition(). Neither case assumes that the failure of x to
be a key is an error:
try:
y = mydict[x]
except KeyError:
process() # working as expected
else:
print 'found x in dict, it shouldn't be there'
sys.exit()
Either way, whether the language uses error codes or exceptions, the
decision of what to do in an exceptional situation is left to the user.
If you'll excuse me pointing out the bleedin' obvious, there are
differences between error codes and exceptions, but they aren't one of
intention. Error codes put the onus on the caller to check the code after
every single call which might fail (or have a buggy program), while
exceptions use a framework that do most of the heavy lifting.
> That's why they have the overhead that they do.
Exceptions don't have one common overhead across all languages that use
them. They have different overhead in different languages -- they're very
heavyweight in C++ and Java, but lightweight in Python. The Perl
Exception::Base module claims to be lightweight. The overhead of
exceptions is related to the implementation of the language.
>> Python uses exceptions for flow control:
>
> Yes, and in some cases I think that's a serious language wart. Not
> enough to put me off the language, but a serious wart nevertheless.
I disagree with that. I think exceptions are a beautiful and powerful way
of dealing with flow control, much better than returning a special code,
and much better than having to check some status function or global
variable, as so often happens in C. They're more restricted, and
therefore safer, than goto. They're not a panacea but they're very useful.
>> Similarly, it's hardly an *error* for [1, 2, 3].index(5) to fail -- who
>> is to say that the list is supposed to have 5 in it? ValueError (a
>> slightly misleading name in this situation) is used to indicate an
>> exceptional, but not unexpected, occurrence.
>
> That one is, I think, a legitimate use of an exception. The result
> returned by index is defined if the index is in bounds. If not, index
> doesn't know whether it was supposed to be in bounds or not, and so
> can't handle the case locally. It could suggest an error or merely
> (IMHO) poor programming. Because index cannot know what the proper
> action is, an exception is the appropriate response.
I think you're confused about what list.index(obj) does. You seem to me
to be assuming that [1,2,3].index(5) should return the item in position 5
of the list, and since there isn't one (5 is out of bounds), raise an
exception. But that's not what it does. It searches the list and returns
the position at which 5 is found.
Of course list.index() could have returned an error code instead, like
str.find() does. But str also has an index() method, which raises an
exception -- when handling strings, you can Look Before You Leap or Ask
For Forgiveness Instead Of Permission, whichever you prefer.
>> Likewise, KeyboardInterrupt is used to allow the user to halt
>> processing; SystemExit is used to shut down the Python virtual machine;
>> and warnings are implemented using exceptions.
>
> Again, I think it's fair to treat a program being killed from outside as
> an exception as far as the program is concerned.
No, it's not being killed from outside the program -- it's being
*interrupted* from *inside* the program by the user. What you do in
response to that interrupt is up to you -- it doesn't necessarily mean
"kill the program".
If you kill the program from outside, using (say) kill or the TaskManager
or something, you don't necessarily get an exception. With kill -9 on
POSIX systems you won't get anything, because the OS will just yank the
carpet out from under your program's feet and then drop a safe on it to
be sure.
--
Steven
Lie Ryan
> Lie Ryan <lie....@gmail.com> writes:
>
>> Paul Rubin wrote:
>>> Steven D'Aprano <st...@REMOVE-THIS-cybersource.com.au> writes:
>>>> For the record, the four lines Paul implies are "confusing" are:
>>>>
>>>> try:
>>>> d[key] += value
>>>> except KeyError:
>>>> d[key] = value
>>> Consider what happens if the computation of "key" or "value" itself
>>> raises KeyError.
>> Isn't key and value just a simple variables/names?
>
> In that example, yes. Paul is encouraging the reader to think of more
> complex cases where they are compound expressions, that can therefore
> raise other errors depending on what those expressions contain.
If key and value had been anything but simple variable/name, then
definitely you're writing the try-block the wrong way. try-block must be
kept as simple as possible.
Here is a simple, and effective way to mitigate the concern about
compound expressions:
key = complex_compound_expression_to_calculate_key
value = complex_compound_expression_to_calculate_value
try:
d[key] += value
except KeyError:
d[key] = value
The point is: "complex expressions and exceptions are used for different
purpose"