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

[Guido van Rossum]

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