[Python-Dev] Re: PEP 285: Adding a bool type (original) (raw)

Ka-Ping Yee ping@lfw.org
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?)