[Python-Dev] Re: PEP 285: Adding a bool type

Wed, 3 Apr 2002 12:06:31 -0600 (CST)

On Wed, 3 Apr 2002, Guido van Rossum wrote:
> You misunderstand it. Strings, lists, numbers and so on are still
> acceptable as truth values, and when you want to know whether x is
> true or false, you still have to say "if x:" -- never "if x == True:".

Yes yes. I understand this part just fine. It's not the *listening*
i'm concerned about -- 'if' takes care of that easily for me. It hears
[], None, 0 as false and hears 'spam', {1: 2}, 47.3 as true.
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.
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!
What about this:
 >>> d = {}
 >>> d[0] = 'zero'
 >>> d[False] = 'false'
 >>> len(d)
 1 or 2?
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. 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.
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...
 >>> 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?)