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

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?)