Op 2005-10-03, Duncan Booth schreef <[EMAIL PROTECTED]>: > Antoon Pardon wrote: > >> Well I'm a bit getting sick of those references to standard idioms. >> There are moments those standard idioms don't work, while the >> gist of the OP's remark still stands like: >> >> egold = 0: >> while egold < 10: >> if test(): >> ego1d = egold + 1 >> > > Oh come on. That is a completely contrived example,
No it is not. You may not have had any use for this kind of code, but unfamiliary with certain types of problems, doesn't make something contrived. > and besides you can > still rewrite it easily using the 'standard idiom' at which point it > becomes rather clearer that it is in danger of being an infinite loop even > without assigning to the wrong variable. > > for egold in range(10): > while test(): > pass And trying to force this into standard idiom is just silly. When people write examples they try to get the essential thing into the example in order to make things clear to other people. The real code they may be a lot more complicated. That you can rework the example into standard idiom doesn't mean the real code someone is working with can be reworked in a like manner. > I find it very hard to believe that anyone would actually mistype ego1d > while intending to type egold (1 and l aren't exactly close on the > keyboard), and if they typed ego1d thinking that was the name of the loop > variable they would type it in both cases (or use 'ego1d += 1') which would > throw an exception. Names do get misspelled and sometimes that misspelling is hard to spot. That you find the specific misspelling used as an example contrived doesn't change that. > The only remaining concern is the case where both ego1d and egold are > existing variables, or more realistically you increment the wrong existing > counter (j instead of i), and your statically typed language isn't going to > catch that either. A language where variable have to be declared before use, would allow to give all misspelled (undeclared) variables in on go, instead of just crashing each time one is encounterd. > I'm trying to think back through code I've written over the past few years, > and I can remember cases where I've ended up with accidental infinite loops > in languages which force me to write loops with explicit incremements, but > I really can't remember that happening in a Python program. Good for you, but you shouldn't limit your view to your experience. > Having just grepped over a pile of Python code, I'm actually suprised to > see how often I use 'while' outside generators even in cases where a 'for' > loop would be sensible. In particular I have a lot of loops of the form: > > while node: > ... do something with node ... > node = node.someAttribute > > where someAttribute is parentNode or nextSibling or something. These would, > of course be better written as for loops with appropriate iterators. e.g. > > for node in node.iterAncestors(): > ... do something with node ... That "of course" is unfounded. They may be better in your specific code, but what you showed is insufficient to decide that. The first code could for instance be reversing the sequence in the part that is labeled ...do something with node ... -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
