Re: The rap against "while True:" loops

[Jorgen Grahn]

On Wed, 2009-10-14, Steven D'Aprano wrote:
...

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

You seem to have experimented with this, so you might be right.

> In C++, exceptions are expensive, whether you catch one or not.

I am not sure that is objectively true, even if you consider that
"expensive" among C++ users often means "costs more than a semi-decent
alternative".  For example, Stroustrup claimed back in 1994 that the
non-catching case can be implemented at no speed cost or no memory
usage cost (Design and Evolution of C++, 1994, p397).

/Jorgen

-- 
  // Jorgen GrahnO  o   .
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Lawrence D'Oliveiro]

In message , kj wrote:

> I use "while True"-loops often, and intend to continue doing this
> "while True" ...

My practice with regard to loops is to use constructs such as "while 
(condition) { ... }" and "do ... while (condition)" where "condition" is the 
ONLY terminating condition (i.e. no "break" statements in the middle). If I 
need to exit in the middle, or have more than one exit, then I switch to 
"for (;;) { ... }" or (Python)" "while True : ...". That way, anybody 
reading the code immediately realizes that the only way out of the loop is 
by one or more exits in the middle.

By the way, in practice some 90% of my loops seem to need either multiple 
exits or an exit in the middle.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Tim Rowe]

2009/10/20 Hendrik van Rooyen :

> So if you want to sum stuff where there are a lot of keys, but only a few
> values per key - say between one and ten, then it would be faster to look
> before you leap.
>
> On the other hand, if there are relatively few keys and tens or hundreds of
> values per key, then you ask for forgiveness.
>
> And if you don't  know what the data is going to look like, then you should
> either go into a catatonic state, or take to the bottle, as the zen of python
> states that you should refuse the temptation to guess.

Might I respectfully suggest that in *all* cases you do whatever is
*clearest*, then switch to the other one if and only if performance is
unacceptable *and* profiling reveals this to be the bottleneck? That
avoids your deadlock (or is it livelock?) state.

-- 
Tim Rowe
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[NiklasRTZ]

On Oct 19, 2:51 am, Hendrik van Rooyen 
wrote:
> On Sunday, 18 October 2009 11:31:19 Paul Rubin wrote:
>
> > Hendrik van Rooyen  writes:
> > > 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:
>
> >   d[key] = value + d.get(key, 0)
>
> I was actually just needling Aahz a bit.  The point I was trying to make
> subliminally, was that there is a relative cost of double lookup for all
> cases versus exceptions for some cases. - Depending on the frequency
> of "some", I would expect a breakeven point.
>
> - Hendrik

Looks similar to this idiomrelated dummyflag and formhandling edit I
try understand some time whether it matters, default=False, same
output, later chosen of nothing else to avoid casting since all inputs
are text and no input is boolean:

view=db.BooleanProperty(default=False,verbose_name="view")

#view = not boo(self.request.get('invisible'))
view = self.request.get('invisible',None) is not None

Easier to keep things positive the longest we can so that above rather
handles variable 'visible' than 'invisible' since double negatives,
triple negatives or more unintelligibilize. Hence a 3rd way, all
positive, shall easify readability, perhaps switch default from false
to true.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Iain King]

On Oct 19, 7:51 am, Hendrik van Rooyen 
wrote:
> On Sunday, 18 October 2009 11:31:19 Paul Rubin wrote:
>
> > Hendrik van Rooyen  writes:
> > > 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:
>
> >   d[key] = value + d.get(key, 0)
>
> I was actually just needling Aahz a bit.  The point I was trying to make
> subliminally, was that there is a relative cost of double lookup for all
> cases versus exceptions for some cases. - Depending on the frequency
> of "some", I would expect a breakeven point.
>
> - Hendrik

Indeed - the method I use for this (picked up from this newsgroup), is
to work out roughly how often you need to make a new record instead of
altering a current one, and depending on that use either:

if key in d:
d[key] += value
else:
d[key] = value

or

try:
d[key] += value
except KeyError:
d[key] = value


I find both to be easily readable (and the similarity between the two
blocks is obvious and, to me at least, pleasing).

Iain
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Hendrik van Rooyen]

On Monday, 19 October 2009 09:43:15 Steven D'Aprano wrote:
> On Mon, 19 Oct 2009 08:51:44 +0200, Hendrik van Rooyen wrote:
> > The point I was trying to make
> > subliminally, was that there is a relative cost of double lookup for all
> > cases versus exceptions for some cases. - Depending on the frequency of
> > "some", I would expect a breakeven point.
>
> There is, at least according to my (long distant and only barely
> remembered) tests.

8< ---
>
> under Python 2.5. However, catching an exception is more expensive,
> approximately ten times more so. Doing a lookup twice falls somewhere
> between the two, closer to the cheap side than the expensive.
>
> So according to my rough estimates, it is faster to use the try...except
> form so long as the number of KeyErrors is less than about one in six,
> give or take. If KeyError is more common than that, it's cheaper to do a
> test first, say with d.has_key(). Using the `in` operator is likely to be
> faster than has_key(), which will shift the break-even point.
>
> (The above numbers are from memory and should be taken with a large pinch
> of salt. Even if they are accurate for me, they will likely be different
> on other machines, and will depend on the actual keys in the dict. In
> other words, your mileage may vary.)

So if you want to sum stuff where there are a lot of keys, but only a few 
values per key - say between one and ten, then it would be faster to look 
before you leap.

On the other hand, if there are relatively few keys and tens or hundreds of 
values per key, then you ask for forgiveness.

And if you don't  know what the data is going to look like, then you should 
either go into a catatonic state, or take to the bottle, as the zen of python 
states that you should refuse the temptation to guess.

This is also known as paralysis by analysis.

:-)

- Hendrik



-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Jaime Buelta]

For me, it's more a question of clarity than anything else. I don't
like very much using break, continue or more than one return per
function on C/C++, but sometimes it's much clearer to use them.
Also, in Python I use them often, as usually the code is cleaner this
way.

for example, I will wrote that code in C/C++

for (i=0;(ihttp://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[inhahe]

On Mon, Oct 19, 2009 at 1:55 PM, inhahe  wrote:

>
>
> On Sat, Oct 10, 2009 at 6:34 PM, Mensanator  wrote:
>
>> On Oct 10, 5:02�pm, kj  wrote:
>> > In <01ccc46d-5ea9-4dfe-ba22-699c6b859...@v36g2000yqv.googlegroups.com>
>> Mensanator  writes:
>> >
>> > In fact, if it were up to me, I would have made the fundamental
>> > looping construct something like
>> >
>> > repeat:
>> > � � � ...
>> > � � � if whatever():
>> > � � � � � �break
>> > � � � ...
>>
>> 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.
>>
>>
> Of course, this is why you would use "while not done" instead of "while
> True" or "repeat" in that situation, so i'm not sure what your contention
> is.
>
>
>> 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.
>>
>>
> This is why I propose an "until" keyword.
>
> until n == 1:
>   ...
>
> i know some people don't like to add keywords "unnecessarily," but i really
> like to be able to express programs in a way that reflects what we actually
> mean, when there's a simple way this could be provided and it's a common use
> case.
>
> i recognize the problem with my solution is that "n" might not even be
> defined until somewhere in the loop after "until n == 1" is evaluated.  this
> makes it a little weird, but it's not strictly a problem since the
> interpreter doesn't actually have to evaluate "n == 1" until the tail end of
> the loop.
>
>
> >
>> > and made all the other looping constructs as syntatic sugar for
>> > this one.
>>
>> Luckily, it's not up to you.
>>
>
> condescending and manipulative, as it merely begs the question of luckily
> for whom -- him, or you
>
>
>> >
>> > kj
>>
>> --
>> http://mail.python.org/mailman/listinfo/python-list
>>
>
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Tim Rowe]

2009/10/18 Steven D'Aprano :

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

Nothing -- because both of those are at the level of code where you
know what to do with the error condition. But if you weren't -- if,
for example, you were in a library routine and had no idea how the
routime might be used in the future -- the latter would just become:
y = mydict[x]
and the problem is passed on until it gets to somebody who does know.
In the former case, though, you still need all the error handling code
even though you don't know how to handle the error, *and* you need to
exit with an error code of your own, *and* your client needs error
handling code even though /they/ might not know how to handle the
error, and so on.

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

They both assume that calling handle_error_condition() is an
appropriate response.

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

As others have pointed out, Python exceptions are cheap to set up, but
decidedly less cheap to invoke. But I'm not making the efficiency
argument, I'm making the clarity argument. I don't /quite/ believe
that Premature Optimisation is the root of all evil, but I wouldn't
avoid exceptions because of the overhead. In the rare cases where the
response to an exceptional condition is time (or resource?)-critical
I'd consider that case to need special handling anyway, and so
wouldn't treat it as an exception.

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

I agree completely -- when they're used in appropriate circumstances.
Not when they're not.

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

Yes, sorry, brain fade. But my point remains that the authors of index
can't know whether the item not being in the list is an error or not,
can't know how to handle that case, and so passing it to the client as
an exception is an appropriate response.

> No, it's not being killed from outside the program -- it's being
> *interrupted* from *inside* the program by the user.

Who -- unless AI has advanced further than I thought -- is *outside*
the program.

-- 
Tim Rowe
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Steven D'Aprano]

On Mon, 19 Oct 2009 08:51:44 +0200, Hendrik van Rooyen wrote:

> The point I was trying to make
> subliminally, was that there is a relative cost of double lookup for all
> cases versus exceptions for some cases. - Depending on the frequency of
> "some", I would expect a breakeven point.

There is, at least according to my (long distant and only barely 
remembered) tests.

Setting up a try...except is very cheap, about as cheap as a pass 
statement. That is:

d = {1: None}
try:
x = d[1]
except KeyError:
print "This can't happen"


is approximately as costly as:

d = {1: None}
pass
x = d[1]

under Python 2.5. However, catching an exception is more expensive, 
approximately ten times more so. Doing a lookup twice falls somewhere 
between the two, closer to the cheap side than the expensive.

So according to my rough estimates, it is faster to use the try...except 
form so long as the number of KeyErrors is less than about one in six, 
give or take. If KeyError is more common than that, it's cheaper to do a 
test first, say with d.has_key(). Using the `in` operator is likely to be 
faster than has_key(), which will shift the break-even point.

(The above numbers are from memory and should be taken with a large pinch 
of salt. Even if they are accurate for me, they will likely be different 
on other machines, and will depend on the actual keys in the dict. In 
other words, your mileage may vary.)



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Hendrik van Rooyen]

On Sunday, 18 October 2009 11:31:19 Paul Rubin wrote:
> Hendrik van Rooyen  writes:
> > 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:
>
>   d[key] = value + d.get(key, 0)

I was actually just needling Aahz a bit.  The point I was trying to make 
subliminally, was that there is a relative cost of double lookup for all 
cases versus exceptions for some cases. - Depending on the frequency 
of "some", I would expect a breakeven point.

- Hendrik



-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[NiklasRTZ]

Russ P. wrote:
> On Oct 10, 1:15
pm, 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, 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".

equivalently appears doable with for statement too, but not C-style for
(;;), however like this
from itertools import count
for a in (2*b in itertools.count() if b**2 > 3):
doThis()
sleep(5)
doThat()

best regards,
NR
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Paul Rubin]

Lie Ryan  writes:
> 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.

Avoiding the try-block completely is the simplest possibility of them all.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Lie Ryan]

Ben Finney wrote:

Lie Ryan  writes:


Paul Rubin wrote:

Steven D'Aprano  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"

--
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Steven D'Aprano]

On Sat, 17 Oct 2009 13:12:52 +0100, Tim Rowe wrote:

> 2009/10/17 Steven D'Aprano :
> 
>> 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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Ben Finney]

Lie Ryan  writes:

> Paul Rubin wrote:
> > Steven D'Aprano  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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Paul Rubin]

Hendrik van Rooyen  writes:
> 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:

  d[key] = value + d.get(key, 0)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Lie Ryan]

Paul Rubin wrote:

Steven D'Aprano  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? Why should it ever 
raises KeyError? The only other error that try-block code could ever 
possibly throw are NameError and possibly MemoryError.

--
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Steven D'Aprano]

On Sat, 17 Oct 2009 23:37:51 -0700, Paul Rubin wrote:

> Steven D'Aprano  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.

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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Hendrik van Rooyen]

On Saturday, 17 October 2009 16:30:55 Aahz wrote:
> In article ,
>
> Tim Rowe   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

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Paul Rubin]

Steven D'Aprano  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.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Steven D'Aprano]

On Sat, 17 Oct 2009 15:22:59 -0700, Paul Rubin wrote:

> Terry Reedy  writes:
>> >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.

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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Paul Rubin]

Terry Reedy  writes:
> >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.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Terry Reedy]

Steven D'Aprano wrote:

On Fri, 16 Oct 2009 18:30:50 +0100, Tim Rowe wrote:


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.


Nicely put. Programmers are exceptional people, but not erroneous, in 
spite of nerd stereotypes ;-).


tjr


--
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Terry Reedy]

Paul Rubin wrote:

a...@pythoncraft.com (Aahz) writes:

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


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

--
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Paul Rubin]

a...@pythoncraft.com (Aahz) writes:
> >   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.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Aahz]

In article <7xmy3peq3s@ruckus.brouhaha.com>,
Paul Rubin   wrote:
>a...@pythoncraft.com (Aahz) writes:
>>
>> 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

That was a trivial example; non-trivial examples not addressed by
defaultdict are left as an exercise for the reader.
-- 
Aahz (a...@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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Paul Rubin]

a...@pythoncraft.com (Aahz) writes:
> 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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Aahz]

In article ,
Tim Rowe   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".
-- 
Aahz (a...@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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Tim Rowe]

2009/10/17 Steven D'Aprano :

> 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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Steven D'Aprano]

On Fri, 16 Oct 2009 18:30:50 +0100, Tim Rowe wrote:

>> 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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Russ P.]

On Oct 10, 1:15 pm, 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, 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.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Bearophile]

Paul Rubin:

>  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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Aahz]

In article ,
Tim Rowe   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 (a...@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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Tim Rowe]

2009/10/15 Steven D'Aprano :

> 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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Tim Rowe]

2009/10/15 Steven D'Aprano :

>> 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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Tim Rowe]

2009/10/11 Philip Semanchuk :
> 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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Mensanator]

On Oct 14, 12:07�pm, Ethan Furman  wrote:
> Mensanator wrote:
> > On Oct 14, 2:19 am, Dennis Lee Bieber  wrote:
>
> >>On Tue, 13 Oct 2009 15:02:09 -0700 (PDT), Mensanator
> >> 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 )
>
> > 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"?

> And it's awesome! �Go Python! �:-D
>
> ~Ethan~

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Mensanator]

On Oct 14, 6:08�pm, Steven D'Aprano  wrote:
> On Wed, 14 Oct 2009 09:34:28 -0700, Mensanator wrote:
> > On Oct 14, 2:19 am, Dennis Lee Bieber  wrote:
> >> On Tue, 13 Oct 2009 15:02:09 -0700 (PDT), Mensanator
> >>  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

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Paul Rubin]

Steven D'Aprano  writes:
> 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.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Steven D'Aprano]

On Wed, 14 Oct 2009 20:17:40 +, Jorgen Grahn wrote:

>> 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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Steven D'Aprano]

On Wed, 14 Oct 2009 18:30:06 +0100, Tim Rowe wrote:

> 2009/10/14 Dennis Lee Bieber :
> 
>>        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 )
> 
> 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!

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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Steven D'Aprano]

On Wed, 14 Oct 2009 09:34:28 -0700, Mensanator wrote:

> On Oct 14, 2:19�am, Dennis Lee Bieber  wrote:
>> On Tue, 13 Oct 2009 15:02:09 -0700 (PDT), Mensanator
>>  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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Rhodri James]

On Wed, 14 Oct 2009 02:26:17 +0100, Mensanator  wrote:


On Oct 13, 5:38�pm, "Rhodri James" 
wrote:
On Tue, 13 Oct 2009 22:59:04 +0100, Mensanator   
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()

--
Rhodri James *-* Wildebeest Herder to the Masses
--
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Tim Rowe]

2009/10/12 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 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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Jack Norton]

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, 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
  
This thread has gotten a lot of posts concerning programming practices 
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
--
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Paul Rubin]

Raymond Hettinger  writes:
> 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.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Raymond Hettinger]

> And I know somebody, in other languages, thinks
> 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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Jorgen Grahn]

On Wed, 2009-10-14, Marco Mariani wrote:
> 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.

/Jorgen

-- 
  // Jorgen GrahnO  o   .
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Jorgen Grahn]

On Mon, 2009-10-12, Grant Edwards wrote:
> On 2009-10-12, Gabriel Genellina  wrote:
>
>>> my_prissy_little_indicator_variable = true
>>> while (my_prissy_little_indicator_variable){
>>> 
>>> }
>>> isn't satisfying because it doesn't guard the  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.

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

-- 
  // Jorgen GrahnO  o   .
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Jorgen Grahn]

On Mon, 2009-10-12, RDrewD wrote:
...
> 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){
> 
> }
> isn't satisfying because it doesn't guard the  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 GrahnO  o   .
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Ethan Furman]

Mensanator wrote:

On Oct 14, 2:19�am, Dennis Lee Bieber  wrote:


On Tue, 13 Oct 2009 15:02:09 -0700 (PDT), Mensanator
 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 )



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~
--
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Tim Rowe]

2009/10/14 Dennis Lee Bieber :

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

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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[MRAB]

Dennis Lee Bieber wrote:

On Tue, 13 Oct 2009 15:02:09 -0700 (PDT), Mensanator
 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...

If anything -- I'd suggest a proposal to add a plainloopas a
keyword in Python, whose effect is equivalent to a "while True", but a
breakmust be used to exit said loop (well, we'll ignore raising an
exception )


I'd prefer it to be called "repeat".
--
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Mensanator]

On Oct 14, 2:19�am, Dennis Lee Bieber  wrote:
> On Tue, 13 Oct 2009 15:02:09 -0700 (PDT), Mensanator
>  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?

>
> � � � � 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 )

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/

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[TerryP]

When all is said and done, is not all looping *basically* equivalent
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.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Tim Rowe]

2009/10/14 Marco Mariani :
> 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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Marco Mariani]

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.


Thankfully, python programmers are less dogmatic, and use whatever makes 
sense to use. I hope.



--
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[TerryP]

Mensanator, thank goodness that was generated :-P
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Mensanator]

On Oct 13, 5:38�pm, "Rhodri James" 
wrote:
> On Tue, 13 Oct 2009 22:59:04 +0100, Mensanator  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?

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

>
> --
> Rhodri James *-* Wildebeest Herder to the Masses

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[greg]

Steven D'Aprano wrote:
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
--
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Paul Rubin]

Steven D'Aprano  writes:
> 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)]
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Rhodri James]

On Tue, 13 Oct 2009 22:59:04 +0100, Mensanator  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.  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
--
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Steven D'Aprano]

On Tue, 13 Oct 2009 14:59:04 -0700, Mensanator 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.

"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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Paul Rubin]

Mensanator  writes:
> 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?

:

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."
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Mensanator]

On Oct 12, 4:59�pm, David C Ullrich  wrote:
> 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"?

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

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Mensanator]

On Oct 13, 11:27�am, Ethan Furman  wrote:
> Mensanator wrote:
> > On Oct 13, 3:44 am, John Reid  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
>
> >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".
>
> 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.

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~

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Ethan Furman]

Mensanator wrote:

On Oct 13, 3:44�am, John Reid  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

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


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~
--
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

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


--
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Mensanator]

On Oct 13, 3:44�am, John Reid  wrote:
> 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?

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Grant Edwards]

On 2009-10-12, Gabriel Genellina  wrote:

>> my_prissy_little_indicator_variable = true
>> while (my_prissy_little_indicator_variable){
>> 
>> }
>> isn't satisfying because it doesn't guard the  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.comouter space ...
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

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


--
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Steven D'Aprano]

On Mon, 12 Oct 2009 11:32:27 -0700, 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.


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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Paul Rubin]

kj  writes:
> 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.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Raymond Hettinger]

[kj]
> 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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Brian Blais]

On Oct 12, 2009, at 15:18 , Falcolas wrote:



Glad to hear, by the way, that you don't use gotos in Python. =D



actually, it is there.  http://entrian.com/goto/

I particularly like the comefrom construct!


bb
--
Brian Blais
bbl...@bryant.edu
http://web.bryant.edu/~bblais



-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[David C Ullrich]

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.


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

--
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Mensanator]

On Oct 12, 2:18 pm, Falcolas  wrote:
> On Oct 12, 12:32 pm, Mensanator  wrote:
>
>
>
>
>
> > On Oct 12, 1:02 pm, John Reid  wrote:
> > > Mensanator wrote:
> > > > On Oct 12, 3:36 am, greg  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.
>
> How do you manage code where you need to drop out of a neatly written
> for or while loop early?

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

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Falcolas]

On Oct 12, 12:32 pm, Mensanator  wrote:
> On Oct 12, 1:02 pm, John Reid  wrote:
> > Mensanator wrote:
> > > On Oct 12, 3:36 am, greg  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.

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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Mensanator]

On Oct 12, 1:02�pm, John Reid  wrote:
> Mensanator wrote:
> > On Oct 12, 3:36 am, greg  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.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Ethan Furman]

Mensanator wrote:

On Oct 12, 3:36�am, greg  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.



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~
--
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[John Reid]

Mensanator wrote:

On Oct 12, 3:36�am, greg  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.

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.


--
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Mensanator]

On Oct 12, 3:36�am, greg  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.

>
> --
> Greg

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Luis Zarrabeitia]

On Monday 12 October 2009 09:47:23 am Xavier Ho wrote:
> On Mon, Oct 12, 2009 at 11:32 PM, Luis Zarrabeitia  wrote:
> > Actually, in python, this works even better:
> >
> > for lin in iter(file_object.readline, ""):
> >... do something with lin
>
> What about 
>
> >>> 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"!


-- 
Luis Zarrabeitia (aka Kyrie)
Fac. de Matemática y Computación, UH.
http://profesores.matcom.uh.cu/~kyrie
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Mel]

Luis Zarrabeitia wrote:

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


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Xavier Ho]

On Mon, Oct 12, 2009 at 11:32 PM, Luis Zarrabeitia  wrote:

> Actually, in python, this works even better:
>
> for lin in iter(file_object.readline, ""):
>... do something with lin
>
>
What about 

>>> with open(path_string) as f:
>>> for line in f:
>>> # do something

Cheers,
Xav
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Luis Zarrabeitia]

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



-- 
Luis Zarrabeitia (aka Kyrie)
Fac. de Matemática y Computación, UH.
http://profesores.matcom.uh.cu/~kyrie
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[greg]

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


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
--
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[greg]

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.

--
Greg
--
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[greg]

RDrewD wrote:


my_prissy_little_indicator_variable = true
while (my_prissy_little_indicator_variable){

}
isn't satisfying because it doesn't guard the  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
--
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[greg]

Steven D'Aprano wrote:
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
--
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Bearophile]

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.


> 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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Peter Billam]

On 2009-10-11, Bearophile  wrote:
> 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.

Peter

-- 
Peter Billam   www.pjb.com.auwww.pjb.com.au/comp/contact.html
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Gabriel Genellina]

En Sun, 11 Oct 2009 23:01:47 -0300, RDrewD  escribió:


On Oct 11, 6:46 pm, Philip Semanchuk  wrote:

On Oct 11, 2009, at 5:51 PM, bartc wrote:
> Mensanator wrote:
>> On Oct 10, 3:15 pm, 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, 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 " 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){

}
isn't satisfying because it doesn't guard the  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

Re: The rap against "while True:" loops

[Gabriel Genellina]

En Sun, 11 Oct 2009 19:46:06 -0300, Philip Semanchuk  
 escribió:

On Oct 11, 2009, at 5:51 PM, bartc wrote:

Mensanator wrote:

On Oct 10, 3:15�pm, 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".[...]


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

--
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[RDrewD]

On Oct 11, 6:46 pm, Philip Semanchuk  wrote:
> On Oct 11, 2009, at 5:51 PM, bartc wrote:
>
>
>
> > Mensanator wrote:
> >> On Oct 10, 3:15 pm, 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, 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 " 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){

}
isn't satisfying because it doesn't guard the  with any
assurance that the loop invariant will be true before you enter into
that block of code.

Similarly, the

Repeat {

if () break

}

doesn't guard the  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:
   
   pc=
   continue
case 2:
   

}
}
# 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  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 

Re: The rap against "while True:" loops

[Philip Semanchuk]

On Oct 11, 2009, at 5:51 PM, bartc wrote:


Mensanator wrote:

On Oct 10, 3:15�pm, 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, 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 " 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
--
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Mensanator]

On Oct 11, 4:51�pm, "bartc"  wrote:
> Mensanator wrote:
> > On Oct 10, 3:15 pm, 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, 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

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[bartc]

Mensanator wrote:

On Oct 10, 3:15�pm, 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, 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.


--
Bartc 


--
http://mail.python.org/mailman/listinfo/python-list

Re: The rap against "while True:" loops

[Gabriel Genellina]

En Sat, 10 Oct 2009 19:32:25 -0300, Björn Lindqvist   
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

--
http://mail.python.org/mailman/listinfo/python-list