Re: The rap against while True: loops
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 Grahn grahn@ Oo o. . . \X/ snipabacken.se O o . -- http://mail.python.org/mailman/listinfo/python-list
Re: The rap against while True: loops
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
On Oct 19, 7:51 am, Hendrik van Rooyen hend...@microcorp.co.za wrote: On Sunday, 18 October 2009 11:31:19 Paul Rubin wrote: Hendrik van Rooyen hend...@microcorp.co.za 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
On Oct 19, 2:51 am, Hendrik van Rooyen hend...@microcorp.co.za
wrote:
On Sunday, 18 October 2009 11:31:19 Paul Rubin wrote:
Hendrik van Rooyen hend...@microcorp.co.za 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
2009/10/20 Hendrik van Rooyen hend...@microcorp.co.za: 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
In message haqq0p$7f...@reader1.panix.com, 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
On Sunday, 18 October 2009 11:31:19 Paul Rubin wrote: Hendrik van Rooyen hend...@microcorp.co.za 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
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
2009/10/18 Steven D'Aprano st...@remove-this-cybersource.com.au: 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
On Mon, Oct 19, 2009 at 1:55 PM, inhahe inh...@gmail.com wrote: On Sat, Oct 10, 2009 at 6:34 PM, Mensanator mensana...@aol.com wrote: On Oct 10, 5:02�pm, kj no.em...@please.post wrote: In 01ccc46d-5ea9-4dfe-ba22-699c6b859...@v36g2000yqv.googlegroups.com Mensanator mensana...@aol.com 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
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;(iMAX) (get_out == True);i++) {
. do lot of things...
if( condition) {
get_out = True
}
}
but in Python will use
for i in range(MAX):
..do lot of things...
if condition:
#Exit the loop
break
Don't know, seems to me that the more syntetic code of Python helps me
to see clearly when to exit, in C/C++ the break statements seems to
confuse me. Probably related with the amount (and density) of code
I think an infinity loop (while True:) should be used only on, well,
infinite loops (or at least indeterminate ones that depends on
arguably input, like user input or network data) I wouldn't use them
for reading a file, for example...
But, anyway, I think the key concept is to use them when it's more
readable and makes more sense than a finite loop. By the way, more
readable to me, of course :-P
--
http://mail.python.org/mailman/listinfo/python-list
Re: The rap against while True: loops
Steven D'Aprano st...@remove-this-cybersource.com.au writes: For the record, the four lines Paul implies are confusing are: try: d[key] += value except KeyError: d[key] = value Consider what happens if the computation of key or value itself raises KeyError. -- http://mail.python.org/mailman/listinfo/python-list
Re: The rap against while True: loops
On Saturday, 17 October 2009 16:30:55 Aahz wrote: In article mailman.1589.1255781573.2807.python-l...@python.org, Tim Rowe digi...@gmail.com wrote: The point is that an exception causes a change in program flow, so of course they're used for flow control. It's what they do. The question is in what cases it's appropriate to use them. Standard Python idiom: try: d[key] += value except KeyError: d[key] = value Maybe you need to re-think appropriate. Standard Python idiom: if key in d: d[key] += value else: d[key] = value Maybe you need to re-think appropriate. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: The rap against while True: loops
On Sat, 17 Oct 2009 23:37:51 -0700, Paul Rubin wrote:
Steven D'Aprano st...@remove-this-cybersource.com.au writes:
For the record, the four lines Paul implies are confusing are:
try:
d[key] += value
except KeyError:
d[key] = value
Consider what happens if the computation of key or value itself
raises KeyError.
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
Paul Rubin wrote: Steven D'Aprano st...@remove-this-cybersource.com.au writes: For the record, the four lines Paul implies are confusing are: try: d[key] += value except KeyError: d[key] = value Consider what happens if the computation of key or value itself raises KeyError. Isn't key and value just a simple variables/names? 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
Hendrik van Rooyen hend...@microcorp.co.za 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 lie.1...@gmail.com writes: Paul Rubin wrote: Steven D'Aprano st...@remove-this-cybersource.com.au writes: For the record, the four lines Paul implies are confusing are: try: d[key] += value except KeyError: d[key] = value Consider what happens if the computation of key or value itself raises KeyError. Isn't key and value just a simple variables/names? In that example, yes. Paul is encouraging the reader to think of more complex cases where they are compound expressions, that can therefore raise other errors depending on what those expressions contain. -- \ “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
On Sat, 17 Oct 2009 13:12:52 +0100, Tim Rowe wrote: 2009/10/17 Steven D'Aprano st...@remove-this-cybersource.com.au: No, you have a fundamental misunderstanding. They're called exceptions, not errors, because they represent exceptional cases. Often errors are exceptional cases, but they're not the only sort of exceptional case. The whole reason for the mechanism, across all languages that have it, is to deal with situations that you don't know how to deal with locally. That confuses me. If I call: y = mydict[x] how does my knowledge of what to do if x is not a key relate to whether the language raises an exception, returns an error code, dumps core, or prints He's not the Messiah, he's a very naughty boy to stderr? You seem to be making a distinction of *intent* which, as far as I can tell, doesn't actually exist. What's the difference in intent between these? y = mydict[x] if y == KeyErrorCode: handle_error_condition() process(y) and this? try: y = mydict[x] except KeyError: handle_error_condition() process(y) Neither assumes more or less knowledge of what to do in handle_error_condition(). Neither case assumes that the failure of x to be a key is an error: try: y = mydict[x] except KeyError: process() # working as expected else: print 'found x in dict, it shouldn't be there' sys.exit() Either way, whether the language uses error codes or exceptions, the decision of what to do in an exceptional situation is left to the user. If you'll excuse me pointing out the bleedin' obvious, there are differences between error codes and exceptions, but they aren't one of intention. Error codes put the onus on the caller to check the code after every single call which might fail (or have a buggy program), while exceptions use a framework that do most of the heavy lifting. That's why they have the overhead that they do. Exceptions don't have one common overhead across all languages that use them. They have different overhead in different languages -- they're very heavyweight in C++ and Java, but lightweight in Python. The Perl Exception::Base module claims to be lightweight. The overhead of exceptions is related to the implementation of the language. Python uses exceptions for flow control: Yes, and in some cases I think that's a serious language wart. Not enough to put me off the language, but a serious wart nevertheless. I disagree with that. I think exceptions are a beautiful and powerful way of dealing with flow control, much better than returning a special code, and much better than having to check some status function or global variable, as so often happens in C. They're more restricted, and therefore safer, than goto. They're not a panacea but they're very useful. Similarly, it's hardly an *error* for [1, 2, 3].index(5) to fail -- who is to say that the list is supposed to have 5 in it? ValueError (a slightly misleading name in this situation) is used to indicate an exceptional, but not unexpected, occurrence. That one is, I think, a legitimate use of an exception. The result returned by index is defined if the index is in bounds. If not, index doesn't know whether it was supposed to be in bounds or not, and so can't handle the case locally. It could suggest an error or merely (IMHO) poor programming. Because index cannot know what the proper action is, an exception is the appropriate response. I think you're confused about what list.index(obj) does. You seem to me to be assuming that [1,2,3].index(5) should return the item in position 5 of the list, and since there isn't one (5 is out of bounds), raise an exception. But that's not what it does. It searches the list and returns the position at which 5 is found. Of course list.index() could have returned an error code instead, like str.find() does. But str also has an index() method, which raises an exception -- when handling strings, you can Look Before You Leap or Ask For Forgiveness Instead Of Permission, whichever you prefer. Likewise, KeyboardInterrupt is used to allow the user to halt processing; SystemExit is used to shut down the Python virtual machine; and warnings are implemented using exceptions. Again, I think it's fair to treat a program being killed from outside as an exception as far as the program is concerned. No, it's not being killed from outside the program -- it's being *interrupted* from *inside* the program by the user. What you do in response to that interrupt is up to you -- it doesn't necessarily mean kill the program. If you kill the program from outside, using (say) kill or the TaskManager or something, you don't necessarily get an exception. With kill -9 on POSIX systems you won't get anything, because the OS will just yank the carpet out from under your program's feet and then drop a safe on it to be sure. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: The rap against while True: loops
Ben Finney wrote: Lie Ryan lie.1...@gmail.com writes: Paul Rubin wrote: Steven D'Aprano st...@remove-this-cybersource.com.au writes: For the record, the four lines Paul implies are confusing are: try: d[key] += value except KeyError: d[key] = value Consider what happens if the computation of key or value itself raises KeyError. Isn't key and value just a simple variables/names? In that example, yes. Paul is encouraging the reader to think of more complex cases where they are compound expressions, that can therefore raise other errors depending on what those expressions contain. If key and value had been anything but simple variable/name, then definitely you're writing the try-block the wrong way. try-block must be kept as simple as possible. Here is a simple, and effective way to mitigate the concern about compound expressions: key = complex_compound_expression_to_calculate_key value = complex_compound_expression_to_calculate_value try: d[key] += value except KeyError: d[key] = value The point is: complex expressions and exceptions are used for different purpose -- http://mail.python.org/mailman/listinfo/python-list
Re: The rap against while True: loops
Lie Ryan lie.1...@gmail.com 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
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
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
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 tjre...@udel.edu 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
On Sat, 17 Oct 2009 15:22:59 -0700, Paul Rubin wrote:
Terry Reedy tjre...@udel.edu 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
2009/10/15 Steven D'Aprano st...@remove-this-cybersource.com.au: 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
2009/10/15 Steven D'Aprano st...@remove-this-cybersource.com.au: 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
In article mailman.1540.1255714251.2807.python-l...@python.org, Tim Rowe digi...@gmail.com wrote: The understood meaning of throwing an exception is to say something happened that shouldn't have. If one uses it when something has happened that *should* have, because it happens to have the right behaviour (even if the overhead doesn't matter), then one is misrepresenting the program logic. Except, of course, that your understood meaning is wrong for Python. Perhaps you should go look up StopIteration. -- Aahz (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: 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
On Oct 10, 1:15 pm, kj no.em...@please.post wrote: I'm coaching a group of biologists on basic Python scripting. One of my charges mentioned that he had come across the advice never to use loops beginning with while True. Of course, that's one way to start an infinite loop, but this seems hardly a sufficient reason to avoid the construct altogether, as long as one includes an exit that is always reached. (Actually, come to think of it, there are many situations in which a bona fide infinite loops (typically within a try: block) is the required construct, e.g. when implementing an event loop.) I use while True-loops often, and intend to continue doing this while True, but I'm curious to know: how widespread is the injunction against such loops? Has it reached the status of best practice? 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
2009/10/11 Philip Semanchuk phi...@semanchuk.com: 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, thank goodness that was generated :-P -- http://mail.python.org/mailman/listinfo/python-list
Re: The rap against while True: loops
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
2009/10/14 Marco Mariani ma...@sferacarta.com: 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
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
On Oct 14, 2:19�am, Dennis Lee Bieber wlfr...@ix.netcom.com wrote: On Tue, 13 Oct 2009 15:02:09 -0700 (PDT), Mensanator mensana...@aol.com declaimed the following in gmane.comp.python.general: You're not getting away that easy. What's YOUR opinion of whilr True? � � � � Uhm... that it isn't valid in any language having English influence upon it's keywords... Duh. You DO know that 'r' is next to 'e' on the keyboard? � � � � If anything -- I'd suggest a proposal to add a plain � �loop � �as a keyword in Python, whose effect is equivalent to a while True, but a break � �must be used to exit said loop (well, we'll ignore raising an exception G) And what will that accomplish? The problem isn't using while True, it's the fact that you are escaping the loop. Best Practice is to EXIT the loop properly, not escape from it. -- � � � � Wulfraed � � � � Dennis Lee Bieber � � � � � � � KD6MOG � � � � wlfr...@ix.netcom.com � � HTTP://wlfraed.home.netcom.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: The rap against while True: loops
Dennis Lee Bieber wrote: On Tue, 13 Oct 2009 15:02:09 -0700 (PDT), Mensanator mensana...@aol.com declaimed the following in gmane.comp.python.general: You're not getting away that easy. What's YOUR opinion of whilr True? Uhm... that it isn't valid in any language having English influence upon it's keywords... 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 G) bikesheddingI'd prefer it to be called repeat./bikeshedding -- http://mail.python.org/mailman/listinfo/python-list
Re: The rap against while True: loops
2009/10/14 Dennis Lee Bieber wlfr...@ix.netcom.com: If anything -- I'd suggest a proposal to add a plain loop as a keyword in Python, whose effect is equivalent to a while True, but a break must be used to exit said loop (well, we'll ignore raising an exception G) And with enough static analysis to guarantee that the break will be reached? I think it would be a bit much to expect Python to solve the halting problem! -- Tim Rowe -- http://mail.python.org/mailman/listinfo/python-list
Re: The rap against while True: loops
Mensanator wrote: On Oct 14, 2:19�am, Dennis Lee Bieber wlfr...@ix.netcom.com wrote: On Tue, 13 Oct 2009 15:02:09 -0700 (PDT), Mensanator mensana...@aol.com declaimed the following in gmane.comp.python.general: You're not getting away that easy. What's YOUR opinion of whilr True? � � � � Uhm... that it isn't valid in any language having English influence upon it's keywords... Duh. You DO know that 'r' is next to 'e' on the keyboard? Not on mine -- it's next to 'o' and 'u'. :-) Go Dvorak! � � � � If anything -- I'd suggest a proposal to add a plain � �loop � �as a keyword in Python, whose effect is equivalent to a while True, but a break � �must be used to exit said loop (well, we'll ignore raising an exception G) And what will that accomplish? The problem isn't using while True, it's the fact that you are escaping the loop. Best Practice is to EXIT the loop properly, not escape from it. I don't think anyone's arguing the opposite. What I *am* seeing argued is if it's the only correct way to do it, and that anyone who does it any other way is a scoundrel and a knave. ;-) For what it's worth, most of my loops run to completion, with no sign of a break anywhere. Some have a break, and use it. Some, even, (dare I say it?) use break *and* else! And it's awesome! Go Python! :-D ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: The rap against while True: loops
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){
body
}
isn't satisfying because it doesn't guard the body with any
assurance that the loop invariant will be true before you enter into
that block of code.
Why not? To me, it obviously does.
It would also help if you didn't use intentionally meaningless and
annoying variable names in your examples. In reality you would have a
meaningful expression like not inputqueue.empty() or
time() deadline or something.
/Jorgen
--
// Jorgen Grahn grahn@ Oo o. . .
\X/ snipabacken.se O o .
--
http://mail.python.org/mailman/listinfo/python-list
Re: The rap against while True: loops
On Mon, 2009-10-12, Grant Edwards wrote:
On 2009-10-12, Gabriel Genellina gagsl-...@yahoo.com.ar wrote:
my_prissy_little_indicator_variable = true
while (my_prissy_little_indicator_variable){
body
}
isn't satisfying because it doesn't guard the body with any
assurance that the loop invariant will be true before you enter into
that block of code.
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 Grahn grahn@ Oo o. . .
\X/ snipabacken.se O o .
--
http://mail.python.org/mailman/listinfo/python-list
Re: The rap against while True: loops
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 Grahn grahn@ Oo o. . . \X/ snipabacken.se O o . -- http://mail.python.org/mailman/listinfo/python-list
Re: The rap against while True: loops
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
Raymond Hettinger pyt...@rcn.com 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
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
2009/10/12 RDrewD drewl...@gmail.com: 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
On Wed, 14 Oct 2009 02:26:17 +0100, Mensanator mensana...@aol.com wrote: On Oct 13, 5:38�pm, Rhodri James rho...@wildebst.demon.co.uk wrote: On Tue, 13 Oct 2009 22:59:04 +0100, Mensanator mensana...@aol.com wrote: And I'm not saying John nor the OP should stop using what works for them. But there are certainly valid reasons for don't use while True to be on the Best Practices list. Unfortunately, some of them seem to be reasons from my point of view to put *do* use while True on the Best Practices list. � Really? Which ones? Some of the constructs you seem to like ring big alarm bells with me, because I've found entirely too many bugs hidden by them. For example? Well, this one's always popular: done = False while not done: do_stuff() done = worry_about_stuff() do_more_stuff_at_great_length() done = worry_about_more_stuff() and_so_on() -- Rhodri James *-* Wildebeest Herder to the Masses -- http://mail.python.org/mailman/listinfo/python-list
Re: The rap against while True: loops
On Wed, 14 Oct 2009 09:34:28 -0700, Mensanator wrote: On Oct 14, 2:19�am, Dennis Lee Bieber wlfr...@ix.netcom.com wrote: On Tue, 13 Oct 2009 15:02:09 -0700 (PDT), Mensanator mensana...@aol.com declaimed the following in gmane.comp.python.general: You're not getting away that easy. What's YOUR opinion of whilr True? Uhm... that it isn't valid in any language having English influence upon it's keywords... Duh. You DO know that 'r' is next to 'e' on the keyboard? Only on QWERTY keyboards. Not on Dvorak keyboards. 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
On Wed, 14 Oct 2009 18:30:06 +0100, Tim Rowe wrote: 2009/10/14 Dennis Lee Bieber wlfr...@ix.netcom.com: If anything -- I'd suggest a proposal to add a plain loop as a keyword in Python, whose effect is equivalent to a while True, but a break must be used to exit said loop (well, we'll ignore raising an exception G) And with enough static analysis to guarantee that the break will be reached? I think it would be a bit much to expect Python to solve the halting problem! 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
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 st...@remove-this-cybersource.com.au 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
On Oct 14, 6:08�pm, Steven D'Aprano st...@remove-this- cybersource.com.au wrote: On Wed, 14 Oct 2009 09:34:28 -0700, Mensanator wrote: On Oct 14, 2:19 am, Dennis Lee Bieber wlfr...@ix.netcom.com wrote: On Tue, 13 Oct 2009 15:02:09 -0700 (PDT), Mensanator mensana...@aol.com declaimed the following in gmane.comp.python.general: You're not getting away that easy. What's YOUR opinion of whilr True? � � � �Uhm... that it isn't valid in any language having English influence upon it's keywords... Duh. You DO know that 'r' is next to 'e' on the keyboard? Only on QWERTY keyboards. Not on Dvorak keyboards. Does anyone actually use those things? Do you know how to proof-read your writing before hitting send? Yeah. And I missed it. Maybe because my laptop has a few broken columns of pixels. If not, please learn. A spell checker may help. Not with Google. If you do know how, if you care so little for what you write that you can't be bothered, why should anyone care enough to read what you write? Conclusion based on false premise. Either way, there's no call for you to be snarky when people call you on stupid typos. I suppose this wasn't snarky: Uhm... that it isn't valid in any language having English influence upon it's keywords... Your mistake could happen to anyone, but it was still *your* mistake. No, it wasn't. You should learn the difference between an error and a mistake. There's nothing to be learned from pointing out a typo. Whereas a mistake, such as using their in place of there should be pointed out so as to prevent future occurences. [...] And what will that accomplish? The problem isn't using while True, it's the fact that you are escaping the loop. That's not a problem. It can be. Best Practice is to EXIT the loop properly, not escape from it. A break does exit the loop properly. That's what it is for, it would be a pretty stupid language that had break exit the loop improperly. Nobody is forcing you to use break. And no one is forcing the OP to stop using while True even if it is not considered Best Practice. You can write Pascal in any language you like. My experience with Pascal is it tended to produce bullet-proof code. The lessons learned from Pascal can only make my Python programs better. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: The rap against while True: loops
On Oct 14, 12:07�pm, Ethan Furman et...@stoneleaf.us wrote: Mensanator wrote: On Oct 14, 2:19 am, Dennis Lee Bieber wlfr...@ix.netcom.com wrote: On Tue, 13 Oct 2009 15:02:09 -0700 (PDT), Mensanator mensana...@aol.com declaimed the following in gmane.comp.python.general: You're not getting away that easy. What's YOUR opinion of whilr True? Uhm... that it isn't valid in any language having English influence upon it's keywords... Duh. You DO know that 'r' is next to 'e' on the keyboard? Not on mine -- it's next to 'o' and 'u'. �:-) �Go Dvorak! Does that mean you think whilr is a word? If anything -- I'd suggest a proposal to add a plain loop as a keyword in Python, whose effect is equivalent to a while True, but a break must be used to exit said loop (well, we'll ignore raising an exception G) And what will that accomplish? The problem isn't using while True, it's the fact that you are escaping the loop. Best Practice is to EXIT the loop properly, not escape from it. I don't think anyone's arguing the opposite. � I get the impression many people are, in fact, arguing the opposite. What I *am* seeing argued is if it's the only correct way to do it, and that anyone who does it any other way is a scoundrel and a knave. �;-) First of all, _I_ didn't bring up the concept of Best Practice, nor have I insisted Best Practice means there is only one correct way to do something. I interpret it as meaning there may be many correct ways to do something, but of those, this is the best way, barring special circumstances. For what it's worth, most of my loops run to completion, with no sign of a break anywhere. �Some have a break, and use it. �Some, even, (dare I say it?) use break *and* else! � Breaks can be used properly, but it's easy to use them improperly. How many of your loops start while True? And it's awesome! �Go Python! �:-D ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: The rap against while True: loops
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
On 2009-10-12, Gabriel Genellina gagsl-...@yahoo.com.ar wrote:
my_prissy_little_indicator_variable = true
while (my_prissy_little_indicator_variable){
body
}
isn't satisfying because it doesn't guard the body with any
assurance that the loop invariant will be true before you enter into
that block of code.
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
On Oct 13, 3:44�am, John Reid j.r...@mail.cryst.bbk.ac.uk 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
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 wrote: On Oct 13, 3:44�am, John Reid j.r...@mail.cryst.bbk.ac.uk wrote: while not done: seems very dangerous to me as you'd have to del done before writing the same construct again. That's the sort of thing that leads to errors. Duh. I won't write silly code like that either. If I need more than one loop structure then I'll do something like � � while not done_with_this � � while not done_with_that 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
On Oct 13, 11:27�am, Ethan Furman et...@stoneleaf.us wrote: Mensanator wrote: On Oct 13, 3:44 am, John Reid j.r...@mail.cryst.bbk.ac.uk wrote: while not done: seems very dangerous to me as you'd have to del done before writing the same construct again. That's the sort of thing that leads to errors. Duh. I won't write silly code like that either. If I need more than one loop structure then I'll do something like while not done_with_this while not done_with_that 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
On Oct 12, 4:59�pm, David C Ullrich ullr...@math.okstate.edu 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
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
On Oct 13, 5:38�pm, Rhodri James rho...@wildebst.demon.co.uk wrote: On Tue, 13 Oct 2009 22:59:04 +0100, Mensanator mensana...@aol.com wrote: And I'm not saying John nor the OP should stop using what works for them. But there are certainly valid reasons for don't use while True to be on the Best Practices list. Unfortunately, some of them seem to be reasons from my point of view to put *do* use while True on the Best Practices list. � Really? Which ones? Some of the constructs you seem to like ring big alarm bells with me, because I've found entirely too many bugs hidden by them. For example? 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 (c1c0) and (c2c1) and (c3c2) and (c4c3) and (c5c4) and (c6c5) and (c7c6) and (c8c7) and (c9c8) and (c10c9) and (c11c10) and (c12c11) and (c13c12) and (c14c13) and (c15c14) and (c16c15) and (c17c16) and (c18c17) and (c19c18)] 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%sc%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
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
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
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
On Mon, Oct 12, 2009 at 11:32 PM, Luis Zarrabeitia ky...@uh.cu wrote: Actually, in python, this works even better: for lin in iter(file_object.readline, ): ... do something with lin 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 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
On Monday 12 October 2009 09:47:23 am Xavier Ho wrote: On Mon, Oct 12, 2009 at 11:32 PM, Luis Zarrabeitia ky...@uh.cu wrote: Actually, in python, this works even better: for lin in iter(file_object.readline, ): ... do something with lin 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
On Oct 12, 3:36�am, greg g...@cosc.canterbury.ac.nz wrote: Mensanator wrote: while not done: � � ... � � if n==1: done = True � � ... Seems to me that 'while not done:' is no better than 'while True:', because in both cases you have to look inside the loop to find out what the exit condition is. Using a more meaningful name for the flag can help, but you can't teach someone that just by giving them an overly simplified rules such as never use while True:. They'll probably just replace it with 'while not done:' and think they've improved things, without ever really understanding the issue. You're missing the point. It's not that you have to look inside for the terminating condition. It's that you don't need a break. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: The rap against while True: loops
Mensanator wrote: On Oct 12, 3:36�am, greg g...@cosc.canterbury.ac.nz wrote: Mensanator wrote: while not done: � � ... � � if n==1: done = True � � ... Seems to me that 'while not done:' is no better than 'while True:', because in both cases you have to look inside the loop to find out what the exit condition is. Using a more meaningful name for the flag can help, but you can't teach someone that just by giving them an overly simplified rules such as never use while True:. They'll probably just replace it with 'while not done:' and think they've improved things, without ever really understanding the issue. You're missing the point. It's not that you have to look inside for the terminating condition. It's that you don't need a break. Nothing wrong with a having a break IMHO. 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 wrote: On Oct 12, 3:36�am, greg g...@cosc.canterbury.ac.nz wrote: Mensanator wrote: while not done: � � ... � � if n==1: done = True � � ... Seems to me that 'while not done:' is no better than 'while True:', because in both cases you have to look inside the loop to find out what the exit condition is. Using a more meaningful name for the flag can help, but you can't teach someone that just by giving them an overly simplified rules such as never use while True:. They'll probably just replace it with 'while not done:' and think they've improved things, without ever really understanding the issue. You're missing the point. It's not that you have to look inside for the terminating condition. It's that you don't need a break. 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
On Oct 12, 1:02�pm, John Reid j.r...@mail.cryst.bbk.ac.uk wrote: Mensanator wrote: On Oct 12, 3:36 am, greg g...@cosc.canterbury.ac.nz wrote: Mensanator wrote: while not done: ... if n==1: done = True ... Seems to me that 'while not done:' is no better than 'while True:', because in both cases you have to look inside the loop to find out what the exit condition is. Using a more meaningful name for the flag can help, but you can't teach someone that just by giving them an overly simplified rules such as never use while True:. They'll probably just replace it with 'while not done:' and think they've improved things, without ever really understanding the issue. You're missing the point. It's not that you have to look inside for the terminating condition. It's that you don't need a break. Nothing wrong with a having a break IMHO. My opinion is that there is everything wrong with having a break. I don't think I have ever used one, I write code that doesn't depend on that crutch. while not done: seems very dangerous to me as you'd have to del done before writing the same construct again. That's the sort of thing that leads to errors. Duh. I won't write silly code like that either. If I need more than one loop structure then I'll do something like while not done_with_this while not done_with_that Besides, since I _always_ initialize the flag before entering a loop, the flag can be reused and doesn't have to be deleted (as long as the loops aren't nested). And since I don't use goto, there's no chance the initialization can be avoided. The best way to avoid the pitfalls of spaghetti code is to not write it in the first place. -- http://mail.python.org/mailman/listinfo/python-list
Re: The rap against while True: loops
On Oct 12, 12:32 pm, Mensanator mensana...@aol.com wrote: On Oct 12, 1:02 pm, John Reid j.r...@mail.cryst.bbk.ac.uk wrote: Mensanator wrote: On Oct 12, 3:36 am, greg g...@cosc.canterbury.ac.nz wrote: Mensanator wrote: while not done: ... if n==1: done = True ... Seems to me that 'while not done:' is no better than 'while True:', because in both cases you have to look inside the loop to find out what the exit condition is. Using a more meaningful name for the flag can help, but you can't teach someone that just by giving them an overly simplified rules such as never use while True:. They'll probably just replace it with 'while not done:' and think they've improved things, without ever really understanding the issue. You're missing the point. It's not that you have to look inside for the terminating condition. It's that you don't need a break. Nothing wrong with a having a break IMHO. My opinion is that there is everything wrong with having a break. I don't think I have ever used one, I write code that doesn't depend on that crutch. while not done: seems very dangerous to me as you'd have to del done before writing the same construct again. That's the sort of thing that leads to errors. Duh. I won't write silly code like that either. If I need more than one loop structure then I'll do something like while not done_with_this while not done_with_that Besides, since I _always_ initialize the flag before entering a loop, the flag can be reused and doesn't have to be deleted (as long as the loops aren't nested). And since I don't use goto, there's no chance the initialization can be avoided. The best way to avoid the pitfalls of spaghetti code is to not write it in the first place. 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
On Oct 12, 2:18 pm, Falcolas garri...@gmail.com wrote: On Oct 12, 12:32 pm, Mensanator mensana...@aol.com wrote: On Oct 12, 1:02 pm, John Reid j.r...@mail.cryst.bbk.ac.uk wrote: Mensanator wrote: On Oct 12, 3:36 am, greg g...@cosc.canterbury.ac.nz wrote: Mensanator wrote: while not done: ... if n==1: done = True ... Seems to me that 'while not done:' is no better than 'while True:', because in both cases you have to look inside the loop to find out what the exit condition is. Using a more meaningful name for the flag can help, but you can't teach someone that just by giving them an overly simplified rules such as never use while True:. They'll probably just replace it with 'while not done:' and think they've improved things, without ever really understanding the issue. You're missing the point. It's not that you have to look inside for the terminating condition. It's that you don't need a break. Nothing wrong with a having a break IMHO. My opinion is that there is everything wrong with having a break. I don't think I have ever used one, I write code that doesn't depend on that crutch. while not done: seems very dangerous to me as you'd have to del done before writing the same construct again. That's the sort of thing that leads to errors. Duh. I won't write silly code like that either. If I need more than one loop structure then I'll do something like while not done_with_this while not done_with_that Besides, since I _always_ initialize the flag before entering a loop, the flag can be reused and doesn't have to be deleted (as long as the loops aren't nested). And since I don't use goto, there's no chance the initialization can be avoided. The best way to avoid the pitfalls of spaghetti code is to not write it in the first place. 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
[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
kj no.em...@please.post 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
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
On Saturday, 10 October 2009 22:15:21 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? Others have given various valid answers, but I have not seen this one: It is often necessary, in long running applications, to set up loops that you would really like to run until the end of time. - the equivalent of a serve forever construct. Then while True is the obvious way to spell it. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: The rap against while True: loops
On Sat, 10 Oct 2009 20:15:21 +, kj wrote: I use while True-loops often, and intend to continue doing this while True, but I'm curious to know: how widespread is the injunction against such loops? Has it reached the status of best practice? Such an injunction probably made more sense back in the days of single- tasking computers. Back in ancient days when dinosaurs walked the Earth, and I was programming in THINK Pascal on Apple Macintosh System 6, I'd go into nervous palpitations writing the equivalent of while True because if I got it wrong, I'd lock up the machine and need to hit the power button. (At least if I was still testing in the THINK Pascal IDE, and had the whole range of debugging options turned on, I could interrupt it.) These days, I must admit I still have a tiny little shiver whenever I write while True, but that's entirely irrational and I pay no attention to it. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: The rap against while True: loops
On 2009-10-11, Hendrik van Rooyen hend...@microcorp.co.za wrote: It is often necessary, in long running applications, to set up loops that you would really like to run until the end of time. - the equivalent of a serve forever construct. Then while True is the obvious way to spell it. Once upon a time I was working on the software requirements specifications for a missile launcher for the US Navy. In the section on the system's scheduler task I wrote something like this: The scheduler shall consist of an infinite loop that executes the following: 1. Call this function. 2. Call that function. [...] The review team (mainly from Johns Hopkins University Applied Physics Lab) told me I couldn't put an infinite loop in the requirements document. I replied, OK, when or under what circumstances do you want the launcher to stop working? They said that I misunderstood their comment. I can (and indeed must) have an infinite loop in the software. I just can't put the phrase infinite loop in the document. They explained that ship captains get to review these documents. Ship captains all took a year of undergrad FORTRAN programming and therefore believe that an infinite loop is a bad thing. I changed the text to read something like this: The secheduler shall repeatedly execute the following until the system is powered off or reset: 1. Call this function. 2. Call that function. [...] Everybody was happy. Tax dollars at work... -- Grant -- http://mail.python.org/mailman/listinfo/python-list
Re: The rap against while True: loops
En Sat, 10 Oct 2009 19:32:25 -0300, Björn Lindqvist bjou...@gmail.com 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
Re: The rap against while True: loops
Mensanator wrote: On Oct 10, 3:15�pm, kj no.em...@please.post wrote: I'm coaching a group of biologists on basic Python scripting. �One of my charges mentioned that he had come across the advice never to use loops beginning with while True. �Of course, that's one way to start an infinite loop, but this seems hardly a sufficient reason to avoid the construct altogether, as long as one includes an exit that is always reached. �(Actually, come to think of it, there are many situations in which a bona fide infinite loops (typically within a try: block) is the required construct, e.g. when implementing an event loop.) I use while True-loops often, and intend to continue doing this while True, but I'm curious to know: how widespread is the injunction against such loops? �Has it reached the status of best practice? If you know this exit that is always reached, why do you pretend not to know it by writing while True? When I'm starting to code something I haven't yet fully worked out, it often starts with an infinite loop like this, until the body is coded and I've figured out how to escape from it. At the end if may or may not be tidied up, depending on how much work it is to reconcile several possible break points into a single terminating condition to be place at one end, and whether that is likely to break or obfuscate a currently working program. But if it's never going to be seen by the brigade who hate all break, exit, goto and multiple return statements, then I won't bother. -- Bartc -- http://mail.python.org/mailman/listinfo/python-list
Re: The rap against while True: loops
On Oct 11, 4:51�pm, bartc ba...@freeuk.com wrote: Mensanator wrote: On Oct 10, 3:15 pm, kj no.em...@please.post wrote: I'm coaching a group of biologists on basic Python scripting. One of my charges mentioned that he had come across the advice never to use loops beginning with while True. Of course, that's one way to start an infinite loop, but this seems hardly a sufficient reason to avoid the construct altogether, as long as one includes an exit that is always reached. (Actually, come to think of it, there are many situations in which a bona fide infinite loops (typically within a try: block) is the required construct, e.g. when implementing an event loop.) I use while True-loops often, and intend to continue doing this while True, but I'm curious to know: how widespread is the injunction against such loops? Has it reached the status of best practice? If you know this exit that is always reached, why do you pretend not to know it by writing while True? When I'm starting to code something I haven't yet fully worked out, it often starts with an infinite loop like this, until the body is coded and I've figured out how to escape from it. 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
On Oct 11, 2009, at 5:51 PM, bartc wrote: Mensanator wrote: On Oct 10, 3:15�pm, kj no.em...@please.post wrote: I'm coaching a group of biologists on basic Python scripting. �One of my charges mentioned that he had come across the advice never to use loops beginning with while True. �Of course, that's one way to start an infinite loop, but this seems hardly a sufficient reason to avoid the construct altogether, as long as one includes an exit that is always reached. �(Actually, come to think of it, there are many situations in which a bona fide infinite loops (typically within a try: block) is the required construct, e.g. when implementing an event loop.) I use while True-loops often, and intend to continue doing this while True, but I'm curious to know: how widespread is the injunction against such loops? �Has it reached the status of best practice? If you know this exit that is always reached, why do you pretend not to know it by writing while True? When I'm starting to code something I haven't yet fully worked out, it often starts with an infinite loop like this, until the body is coded and I've figured out how to escape from it. At the end if may or may not be tidied up, depending on how much work it is to reconcile several possible break points into a single terminating condition to be place at one end, and whether that is likely to break or obfuscate a currently working program. But if it's never going to be seen by the brigade who hate all break, exit, goto and multiple return statements, then I won't bother. I think you bring up a good point. I think while True has some legitimate uses (like event loops), and I don't mind seeing it there. What I don't like is goto, and to a lesser extent break, exit, and multiple returns. I don't find too many cases where they're the clearest way to express things. And where one sees a while True, one can almost always find a break or two lurking in the loop. IMHO, break, goto, etc. have their place, but they're ripe for abuse which leads to spaghetti code. Since the OP is teaching non- programmers to write code, I think the potential for abuse is especially important to keep in mind. I'd think that teaching them a tool like while True would encourage the code now, design later trap that even experienced programmers -- including myself -- sometimes fall into. Writing while condition instead forces one to stop at the beginning of the loop and think at least a little about exactly what it's meant to accomplish. 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
On Oct 11, 6:46 pm, Philip Semanchuk phi...@semanchuk.com wrote:
On Oct 11, 2009, at 5:51 PM, bartc wrote:
Mensanator wrote:
On Oct 10, 3:15 pm, kj no.em...@please.post wrote:
I'm coaching a group of biologists on basic Python scripting. One
of my charges mentioned that he had come across the advice never
to use loops beginning with while True. Of course, that's one
way to start an infinite loop, but this seems hardly a sufficient
reason to avoid the construct altogether, as long as one includes
an exit that is always reached. (Actually, come to think of it,
there are many situations in which a bona fide infinite loops
(typically within a try: block) is the required construct, e.g.
when implementing an event loop.)
I use while True-loops often, and intend to continue doing this
while True, but I'm curious to know: how widespread is the
injunction against such loops? Has it reached the status of best
practice?
If you know this exit that is always reached,
why do you pretend not to know it by writing
while True?
When I'm starting to code something I haven't yet fully worked out,
it often starts with an infinite loop like this, until the body is
coded and I've figured out how to escape from it.
At the end if may or may not be tidied up, depending on how much
work it is to reconcile several possible break points into a single
terminating condition to be place at one end, and whether that is
likely to break or obfuscate a currently working program.
But if it's never going to be seen by the brigade who hate all
break, exit, goto and multiple return statements, then I won't bother.
I think you bring up a good point. I think while True has some
legitimate uses (like event loops), and I don't mind seeing it there.
What I don't like is goto, and to a lesser extent break, exit, and
multiple returns. I don't find too many cases where they're the
clearest way to express things. And where one sees a while True, one
can almost always find a break or two lurking in the loop.
IMHO, break, goto, etc. have their place, but they're ripe for abuse
which leads to spaghetti code. Since the OP is teaching non-
programmers to write code, I think the potential for abuse is
especially important to keep in mind. I'd think that teaching them a
tool like while True would encourage the code now, design later
trap that even experienced programmers -- including myself --
sometimes fall into. Writing while condition instead forces one to
stop at the beginning of the loop and think at least a little about
exactly what it's meant to accomplish.
I was a bit surprised that nobody in this discussion so far bantered
around the phrase loop invariant, but then I looked in
http://en.wikipedia.org/wiki/Loop_invariant and found it was draped in
so much formalism that it's sure to put off all but the most dedicated
of Computer Science fans. I haven't been in college in 35 years, so
I'll admit to being rusty on this, but as I remember it, any time we
wrote a loop, we were expected to be able to say what the loop
invariant is.
my_prissy_little_indicator_variable = true
while (my_prissy_little_indicator_variable){
body
}
isn't satisfying because it doesn't guard the body with any
assurance that the loop invariant will be true before you enter into
that block of code.
Similarly, the
Repeat {
first part
if (exit condition) break
second part
}
doesn't guard the first part code. Worse, when you get to the
Repeat in reading the code, you get no clue about when the loop will
terminate, except maybe for a comment that someone helpfully put by
the loop, but as the program evolves, the comments often lie.
I don't mind while(true) for the case of do forever like those
launcher requirements Peter Billam wrote about up above in this
thread. It essentially says the loop invariant is that the system
hasn't crashed yet. But beware of the universal structured
program:
pc=1
while(pc!=0){
select(pc){
case 1:
body1
pc=next block #
continue
case 2:
body2
}
}
# Look Ma! No goto statements
There are no goto statements but the universal structured program
has no meaningful structure visible to the casual reader's eye..
By making the setting of PC in each case be conditional, you can send
the program to any bodyN that you want. (Think of pc as standing
for program counter and you can see this has as much structure as
assembler language. Very hard to judge that the code always keeps
array references within bounds and that all loops are only entered
when the loop invariant holds and that the loops always terminate when
the loop invariant no longer holds. You might as well be programming
like its 1959. See, it wasn't just the presence of goto's that was
harmful, it was the lack of careful construction of the program that
was harmful.
And just to dust off
Re: The rap against while True: loops
En Sun, 11 Oct 2009 19:46:06 -0300, Philip Semanchuk phi...@semanchuk.com escribió: On Oct 11, 2009, at 5:51 PM, bartc wrote: Mensanator wrote: On Oct 10, 3:15�pm, kj no.em...@please.post wrote: I'm coaching a group of biologists on basic Python scripting. �One of my charges mentioned that he had come across the advice never to use loops beginning with while True.[...] If you know this exit that is always reached, why do you pretend not to know it by writing while True? When I'm starting to code something I haven't yet fully worked out, it often starts with an infinite loop like this, until the body is coded and I've figured out how to escape from it. At the end if may or may not be tidied up, depending on how much work it is to reconcile several possible break points into a single terminating condition to be place at one end, and whether that is likely to break or obfuscate a currently working program. I think you bring up a good point. I think while True has some legitimate uses (like event loops), and I don't mind seeing it there. What I don't like is goto, and to a lesser extent break, exit, and multiple returns. I don't find too many cases where they're the clearest way to express things. And where one sees a while True, one can almost always find a break or two lurking in the loop. IMHO, break, goto, etc. have their place, but they're ripe for abuse which leads to spaghetti code. Since the OP is teaching non-programmers to write code, I think the potential for abuse is especially important to keep in mind. I'd think that teaching them a tool like while True would encourage the code now, design later trap that even experienced programmers -- including myself -- sometimes fall into. Writing while condition instead forces one to stop at the beginning of the loop and think at least a little about exactly what it's meant to accomplish. I don't think so; forcing ALL loops to have the condition at the start is unnatural in some cases. Some loops are best written with the condition at the end (do/while or repeat/until in Pascal) and some loops require a test in the middle (in Python, while True: + break, because we don't have an unconditional loop). In addition, isn't it easier to figure out how this loop ends -- while (condition1) and (condition2) and (condition3): ...lots of code here... than this one? while True: ...lots of code here... if not condition1: break ...lots of code here... if not condition2: break ...lots of code here... if not condition3: break For a loop that can be written as the first one above, sure, that's pretty explicit. For a loop as the second one, try to rewrite it with the condition at the start: you'll end with duplicated tests and/or duplicated code and/or artificial boolean variables added. Some algorithms are *naturally* expressed as a loop with the condition in the middle. Forcing the condition to always happen at the start requires artificial steps that complicate unnecesarily the code. -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
Re: The rap against while True: loops
En Sun, 11 Oct 2009 23:01:47 -0300, RDrewD drewl...@gmail.com escribió:
On Oct 11, 6:46 pm, Philip Semanchuk phi...@semanchuk.com wrote:
On Oct 11, 2009, at 5:51 PM, bartc wrote:
Mensanator wrote:
On Oct 10, 3:15 pm, kj no.em...@please.post wrote:
I'm coaching a group of biologists on basic Python scripting. One
of my charges mentioned that he had come across the advice never
to use loops beginning with while True. Of course, that's one
way to start an infinite loop, but this seems hardly a sufficient
reason to avoid the construct altogether, as long as one includes
an exit that is always reached. (Actually, come to think of it,
there are many situations in which a bona fide infinite loops
(typically within a try: block) is the required construct, e.g.
when implementing an event loop.)
I use while True-loops often, and intend to continue doing this
while True, but I'm curious to know: how widespread is the
injunction against such loops? Has it reached the status of best
practice?
If you know this exit that is always reached,
why do you pretend not to know it by writing
while True?
When I'm starting to code something I haven't yet fully worked out,
it often starts with an infinite loop like this, until the body is
coded and I've figured out how to escape from it.
At the end if may or may not be tidied up, depending on how much
work it is to reconcile several possible break points into a single
terminating condition to be place at one end, and whether that is
likely to break or obfuscate a currently working program.
But if it's never going to be seen by the brigade who hate all
break, exit, goto and multiple return statements, then I won't bother.
I think you bring up a good point. I think while True has some
legitimate uses (like event loops), and I don't mind seeing it there.
What I don't like is goto, and to a lesser extent break, exit, and
multiple returns. I don't find too many cases where they're the
clearest way to express things. And where one sees a while True, one
can almost always find a break or two lurking in the loop.
IMHO, break, goto, etc. have their place, but they're ripe for abuse
which leads to spaghetti code. Since the OP is teaching non-
programmers to write code, I think the potential for abuse is
especially important to keep in mind. I'd think that teaching them a
tool like while True would encourage the code now, design later
trap that even experienced programmers -- including myself --
sometimes fall into. Writing while condition instead forces one to
stop at the beginning of the loop and think at least a little about
exactly what it's meant to accomplish.
I was a bit surprised that nobody in this discussion so far bantered
around the phrase loop invariant, but then I looked in
http://en.wikipedia.org/wiki/Loop_invariant and found it was draped in
so much formalism that it's sure to put off all but the most dedicated
of Computer Science fans. I haven't been in college in 35 years, so
I'll admit to being rusty on this, but as I remember it, any time we
wrote a loop, we were expected to be able to say what the loop
invariant is.
my_prissy_little_indicator_variable = true
while (my_prissy_little_indicator_variable){
body
}
isn't satisfying because it doesn't guard the body with any
assurance that the loop invariant will be true before you enter into
that block of code.
I think you meant the other way; the above is the simplest loop case, with
the test at the start. A loop with the test at the end, on the other hand,
is slightly harder to prove correct (but not much).
As an example, Ada has a general loop construct like this:
loop
...
exit when some_condition;
...
end loop;
and LOTS of work has been done in proving correctness of Ada programs, so
having the test at the start/middle/end of the loop is not an obstacle for
formal verification.
--
Gabriel Genellina
--
http://mail.python.org/mailman/listinfo/python-list
The rap against while True: loops
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: The rap against while True: loops
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? The injunction is nonexistent (save perhaps in people coming from another language who insist that Python just /must/ have a proper do-while construct). while True with an exit-test at the end is idiomatic, how you spell do-while in Python. There's nothing at all wrong with it, and no real Python programmer will ever say don't-do-it. Okay, some people prefer to spell it 'while 1', but its the same difference. Yeah, you have to be certain the exit condition is there and properly formed so it can exit (unless you're using a generator which never empties, of course). But you have to make sure you have a proper exit condition on any looping construct anyways. No idea where your charge came across the advice, but its nonsense. Has it reached the status of best practice? Its simply the correct way to spell a do-while or intentionally infinite loop in Python, always has been. HTH, --S -- http://mail.python.org/mailman/listinfo/python-list
Re: The rap against while True: loops
I agree there is no rap against while True-loops. As an example these are very useful especially when receiving continuous data over a queue, pipe socket, or over any other connection. You set to block, receive data, then process data and finally loop around to wait for next data segment. Of course should protect against problems with try-except wrappers and by handling exit conditions (e.g. break) when appropriate. Is the problem with the specific syntax while True: or is it with having infinite loop constructs at all? --- On Sat, 10/10/09, Stephen Hansen apt.shan...@gmail.com wrote: From: Stephen Hansen apt.shan...@gmail.com Subject: Re: The rap against while True: loops To: python-list@python.org Date: Saturday, October 10, 2009, 8:30 PM 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? The injunction is nonexistent (save perhaps in people coming from another language who insist that Python just /must/ have a proper do-while construct). while True with an exit-test at the end is idiomatic, how you spell do-while in Python. There's nothing at all wrong with it, and no real Python programmer will ever say don't-do-it. Okay, some people prefer to spell it 'while 1', but its the same difference. Yeah, you have to be certain the exit condition is there and properly formed so it can exit (unless you're using a generator which never empties, of course). But you have to make sure you have a proper exit condition on any looping construct anyways. No idea where your charge came across the advice, but its nonsense. Has it reached the status of best practice? Its simply the correct way to spell a do-while or intentionally infinite loop in Python, always has been. HTH, --S -Inline Attachment Follows- -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: The rap against while True: loops
On Oct 10, 3:15�pm, kj no.em...@please.post wrote: I'm coaching a group of biologists on basic Python scripting. �One of my charges mentioned that he had come across the advice never to use loops beginning with while True. �Of course, that's one way to start an infinite loop, but this seems hardly a sufficient reason to avoid the construct altogether, as long as one includes an exit that is always reached. �(Actually, come to think of it, there are many situations in which a bona fide infinite loops (typically within a try: block) is the required construct, e.g. when implementing an event loop.) I use while True-loops often, and intend to continue doing this while True, but I'm curious to know: how widespread is the injunction against such loops? �Has it reached the status of best practice? If you know this exit that is always reached, why do you pretend not to know it by writing while True? TIA! kynn -- http://mail.python.org/mailman/listinfo/python-list
Re: The rap against while True: loops
In 01ccc46d-5ea9-4dfe-ba22-699c6b859...@v36g2000yqv.googlegroups.com Mensanator mensana...@aol.com writes: On Oct 10, 3:15=EF=BF=BDpm, kj no.em...@please.post wrote: I'm coaching a group of biologists on basic Python scripting. =EF=BF=BDOn= e of my charges mentioned that he had come across the advice never to use loops beginning with while True. =EF=BF=BDOf course, that's one way to start an infinite loop, but this seems hardly a sufficient reason to avoid the construct altogether, as long as one includes an exit that is always reached. =EF=BF=BD(Actually, come to think of it, there are many situations in which a bona fide infinite loops (typically within a try: block) is the required construct, e.g. when implementing an event loop.) I use while True-loops often, and intend to continue doing this while True, but I'm curious to know: how widespread is the injunction against such loops? =EF=BF=BDHas it reached the status of bes= t practice? If you know this exit that is always reached, why do you pretend not to know it by writing while True? There's no pretense of anything. I just happen to prefer the directness of this: while True: ... if test_that_always_succeeds_eventually(): break ... over the unnecessary fussiness of this: my_prissy_little_indicator_variable = True while my_prissy_little_indicator_variable: ... if test_that_always_succeeds_eventually(): my_prissy_little_indicator_variable = False continue # oh boy this is going to be fun! ... In fact, if it were up to me, I would have made the fundamental looping construct something like repeat: ... if whatever(): break ... and made all the other looping constructs as syntatic sugar for this one. kj -- http://mail.python.org/mailman/listinfo/python-list
Re: The rap against while True: loops
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. Often it is possible to reformulate while True to a generator which I think is much preferable (such as in the event loop example). Recursive functions can also be more readable than while True because it is easier to make the exit condition explicit. But sometimes they are necessary and then you have to be careful to check that the while True always breaks somewhere. 2009/10/10 kj no.em...@please.post: 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 -- http://mail.python.org/mailman/listinfo/python-list -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: The rap against while True: loops
On Oct 10, 5:02�pm, kj no.em...@please.post wrote: In 01ccc46d-5ea9-4dfe-ba22-699c6b859...@v36g2000yqv.googlegroups.com Mensanator mensana...@aol.com writes: On Oct 10, 3:15=EF=BF=BDpm, kj no.em...@please.post wrote: I'm coaching a group of biologists on basic Python scripting. =EF=BF=BDOn= e of my charges mentioned that he had come across the advice never to use loops beginning with while True. =EF=BF=BDOf course, that's one way to start an infinite loop, but this seems hardly a sufficient reason to avoid the construct altogether, as long as one includes an exit that is always reached. =EF=BF=BD(Actually, come to think of it, there are many situations in which a bona fide infinite loops (typically within a try: block) is the required construct, e.g. when implementing an event loop.) I use while True-loops often, and intend to continue doing this while True, but I'm curious to know: how widespread is the injunction against such loops? =EF=BF=BDHas it reached the status of bes= t practice? If you know this exit that is always reached, why do you pretend not to know it by writing while True? There's no pretense of anything. �I just happen to prefer the directness of this: while True: � � ... � � if test_that_always_succeeds_eventually(): � � � � �break � � ... over the unnecessary fussiness of this: my_prissy_little_indicator_variable = True while my_prissy_little_indicator_variable: � � ... � � if test_that_always_succeeds_eventually(): � � � � my_prissy_little_indicator_variable = False � � � � continue �# oh boy this is going to be fun! � � ... In fact, if it were up to me, I would have made the fundamental looping construct something like repeat: � � � ... � � � if whatever(): � � � � � �break � � � ... So, the second set of '...' doesn't get executed. When I use while not done: ... if n==1: done = True ... the loop will actually complete (which is what I want) instead of aborting, like yours does. I just don't want the loop to execute again. If there are things that should not be done, I explicity have the code check that: ... if not done: write_to_file(test) ... But even if some things are skipped, others need not be: n += 1 ... Now, if I did a break before writing to the file, I would have to do all kinds of clean-up code outside the loop, code that would be run only if the exit were abnormal. and made all the other looping constructs as syntatic sugar for this one. Luckily, it's not up to you. kj -- http://mail.python.org/mailman/listinfo/python-list
Re: The rap against while True: loops
On 2009-10-10, kj no.em...@please.post wrote:
I use while True-loops often, and intend to continue doing this
while True, but I'm curious to know: how widespread is the
injunction against such loops? Has it reached the status of
best practice?
This trend is ironic; I remember in the structured-programming
revolution the
loop { ... if whatever {break;} ... }
idiom was The Recommended looping structure, because the code is
more maintainable. With a while () {...} idiom, you commit
yourself to a bug-prone rewrite if you ever need to insert a
statement before the first break-test, and likewise with a
repeat { ... } until () you commit yourself to a rewrite if
you ever need to insert a statement after the last break-test.
Also, it replaces a multitude of idioms (while, repeat, for,
foreach, map, ...) with one simple idiom which works in all
cases, including in all languages (OK, except functional).
The for item in list idiom is wonderfully readable if you
know that's all you'll ever want to do, but for more general
loops there are still arguments in favour of while True
Infinite loops, well they're quickly noticed in development,
just like stack-crashes are in stack-based languages.
They can occur in other loop-idioms too, like if you
append to your list, or adjust the looping index.
JMHO, Regards, Peter
--
Peter Billam www.pjb.com.auwww.pjb.com.au/comp/contact.html
--
http://mail.python.org/mailman/listinfo/python-list
Re: The rap against while True: loops
kj wrote: I use while True-loops often, and intend to continue doing this while True, Me too. Of course, in Python, 'while True' actually means 'while ^C not pressed and window not closed and process not killed:', whereas in old mainframe Fortran the equivalent might have meant 'while my account not emptied', which tended to engender a fear of such loops. tjr -- http://mail.python.org/mailman/listinfo/python-list
