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