It's the *speaking*. When i want to say true or false, then there's the dilemma.
I know, your answer is "you should always just say True or False", and Mark McEahern said the same thing. But this cannot be so in practice: *everything* already returns 0 or 1. (It may be possible to get around this if we commit to changing the entire standard library before releasing a version of Python with True and False, but alas, this is not the only issue... read on.)
As long as True and False are somewhere represented as 0 and 1, the values 0 and 1 will never lose legitimacy as booleans. This business with str() and/or repr() producing "0" or "1" for backwards compatibility prevents us from considering 0 and 1 relegated to a truly non-boolean status.
But that's a variant of the PEP that no-one except Marc-Andre has spoken in favor of. The PEP proposes str(True) == "True".
Consider this:
>>> a = [0, False, 1, True]
>>> print a [0, 0, 1, 1]
>>> for x in a: print x 0 0 1 1
Good heavens!
It will print 0 False 1 True
What about this:
>>> d = {} >>> d[0] = 'zero' >>> d[False] = 'false' >>> len(d) 1 or 2?
What about this: >>> d = {} >>> d[0] = 'int' >>> d[0.0] = 'float' >>> d[0j] = 'complex' >>> print len(d) 1 or 3? False and True are numbers, and they are equal (==) to 0 and 1; everything else follows from there.
Basically, the concept of having a permanently schizophrenic type in the language scares me. The above shows, i believe, that a reasonable implementation must print True as True and False as False, and never mention 1 or 0.
And this is what the PEP proposes (despite its brief mention of an alternative).
Moreover, as soon as you start sorting a bag of objects, or keying dictionaries on objects, you are forced to run into the distinction between 0 and False, and between 1 and True.
No you're not. d[0] and d[False] retrieve the same value, as do d[0L], d[0.0], and d[0j].
I'm not against the idea of booleans, of course -- but i do think that halfway booleans are worse than what we have now. And getting to real booleans [*] involves real pain; it's just a question of whether that pain is worth it. Even if we get all the way there -- as in we manage to convert enough code and convince everyone to use the new style -- i will never ever want "and" and "or" to return booleans (i just hope that doesn't confuse anyone).
-- ?!ng
[*] By real booleans, i mean the following. (Booleans would have to behave like this for me to consider them "good enough" to be better than what we have now.)
>>> False, repr(False), str(False) (False, 'False', 'False') >>> True, repr(False), str(False) (True, 'False', 'False') >>> False + True TypeError...
That's just one textbook idea of what a Boolean "should" be.
>>> False == None 0 >>> False == 0 0 >>> True == 1 0 >>> {0: 0, False: False, 1: 1, True: True} {0: 0, False: False, 1: 1, True: True}
... and probably
>>> None < False < True < 0 True
(Hee hee -- i suppose the fact that "boolean" starts with a "b" gets us this for free. But i wonder how many people are going to be puzzled by True < 0?)
Yuck. --Guido van Rossum (home page: http://www.python.org/~guido/)