En Sun, 11 Oct 2009 23:01:47 -0300, RDrewD <drewl...@gmail.com> escribió:
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
--
http://mail.python.org/mailman/listinfo/python-list
