PEP-308 a "simplicity-first" alternative

Tim Peters tim_one at email.msn.com
Sun Feb 16 23:20:17 EST 2003


[Erik Max Francis]
> ...
> We've already seen several examples from the standard library (whether
> corrected later or not) that used the idiom incorrectly;

I've seen exactly one, found by Andrew Koenig, where the difference was
between printing "1 test" (intended) and "1 tests" (actual) -- it was truly
of no consequence.

> we're well past the theoretical question of whether and/or can be
> misunderstood and misused.

On that basis, list slicing is much more dangerous in real life, because
(for example) "the idiom"

    list[-i:]

doesn't return the last i list items when i happens to be 0, and I've seen
that bug in real code many times.  Pick just about any operation, and *some*
real-life code has suffered due to using it incorrectly.  The and/or trick
simply isn't a significant source of bugs in real life (not because it's
robust, but because it is fragile it's rarely used in tricky situations).

A full-fledged conditional expression may or may not prove less error-prone
in practice.  I wager it would have squashed the inconsequential bug Andrew
found, but the std library mostly uses and/or for very simple selections
where its use is obviously correct, and I wager too that a full-fledged
conditional expression will get used for more complicated selections.  That
carries risks of introducing new bugs.  Regardless, since there are no known
and/or bugs in current CVS (the unittest pluralization buglet was fixed 8
months ago), the introduction of a conditional expression won't improve the
std library's correctness.






More information about the Python-list mailing list