== Sometimes bugs have very small edit distances

One of the consequences of [[yesterday's SAN backend failure
../sysadmin/NoneventElements]] is that I found a bug in our spares
handling code. It was the kind of bug where the program aborts, and when
that happens we started getting email with Python exception backtraces
that ended in what struck me as a very odd exception:

> _KeyError: False_

Normally KeyErrors make a kind of sense, in that you see what
you're looking up and the question is either why you wound up using
that key or why that key isn't present when you thought it would
be. _KeyError: False_ was so far out of left field that it left me lost
until I finally stared at my code long enough to spot the problem.

It turns out that there is a world of difference between the following
two (summarized) list comprehensions:

> (([... if x['vdev_state' == 'resilvering']])) \\
> (([... if x['vdev_state'] == 'resilvering']))

Yes indeed, looking up the results of a (constant) string equality
comparison is rather different from looking up the value of a key and
then comparing it with a string, even though the difference between the
two is only a repositioned '_]_' (and the first doesn't look obviously
wrong when you're skimming). For a start, one works and the other
complains that you've never put _False_ in your property dict.

(The classical short edit distance mistake is of course C's '_=_' for
'_==_' error, which is not possible in Python.)

One awkward thing that this reveals is that I clearly never actually
tested this code (whether with unit tests or just trying to make sure
that it works). But that's another entry that reveals my ignorance of
how to do TDD right.