true/false inconsistency in Python

John Benson jsbenson at bensonsystems.com
Fri Nov 14 13:00:21 EST 2003


In C, we had one false value (zero) and billions of true values (nonzeroes). That was incredibly convenient from a code brevity standpoint, and you just had to read, learn or somehow figure out that explicit comparison of two pseudo-boolean values was just plain unreliable, unless at least one was zero. Other languages and assembler programming idioms often worked the same way.

In Python, we have lots of false values (zero, None, empty containers) and billions of true values (nonzeroes, nonempty containers). This means that you can't reliably compare pseudo-booleans even when one is known to be false.

In all my C book reading, I've only seen the warning against explicit comparison of pseudo-booleans once or twice. I don't recall seeing the warning in any Python documentation so far, and I've gone through a fair amount of it.

What we have here is a situation where many people came to Python from C and other backgrounds where you were "assumed to know" that

if (condition)
   ...

was always preferred

if (condition == 1)

or even worse, 

#define TRUE (something nonzero)

if (condition == TRUE)

That's probably why this deeply ingrained assumption never made it into documentation: same reason you don't see admonitions to check your side mirror before changing lanes in the little owner's manuals that come with new cars. Not that it's unimportant, but that it didn't seem the right place for this and a myriad of other details, no less critical for the preservation of life and limb.

This is not to minimize the concern, merely to explain why things are the way they are. What ought to be done about it is another matter altogether.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20031114/0d4ff20a/attachment.html>


More information about the Python-list mailing list