The rap against "while True:" loops

[Iain King]

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

 

[NiklasRTZ]

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.

 

[Tim Rowe]

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.

 

[Lawrence D'Oliveiro]

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.

 

[Jorgen Grahn]

.

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