PEP 285: Adding a bool type

[Erik Max Francis]

Guido van Rossum wrote:

> I offer the following PEP for review by the community.  If it receives
> a favorable response, it will be implemented in Python 2.3.

Outstanding!  I've been waiting and hoping for Booleans in Python since
I first was introduced to it.

>     I'm particularly interested in hearing your opinion about the
>     following three issues:
> 
>     1) Should this PEP be accepted at all.

Yes, I believe so.

>     2) Should str(True) return "True" or "1": "1" might reduce
>        backwards compatibility problems, but looks strange to me.
>        (repr(True) would always return "True".)

I agree with you; having repr(True) == str(True) == "True" makes sense
to me.

>     3) Should the constants be called 'True' and 'False'
>        (corresponding to None) or 'true' and 'false' (as in C++, Java
>        and C99).

I'm also a C, C++, and Java guy, but I think that True and False (rather
than true and false) are more Python, as you say, given None.  Internal
consistency makes more sense to me than matching other languages.

>     4) Should we strive to eliminate non-Boolean operations on bools
>        in the future, through suitable warnings, so that e.g. True+1
>        would eventually (e.g. in Python 3000 be illegal).  Personally,
>        I think we shouldn't; 28+isleap(y) seems totally reasonable to
>        me.

No strong opinion here; either solution seems acceptable to me.

>     5) Should operator.truth(x) return an int or a bool.  Tim Peters
>        believes it should return an int because it's been documented
>        as such.  I think it should return a bool; most other standard
>        predicates (e.g. issubtype()) have also been documented as
>        returning 0 or 1, and it's obvious that we want to change those
>        to return a bool.

No strong opinion here either, leaning toward leaving it be.  I think it
should return a bool, since it's effectively converting an arbitrary
expression to a Boolean, but with a bool type and the new trends toward
type unification, one could write bool(expr), which should be the
equivalent of operator.truth(expr) but with type bool, and is shorter.

>     Because the repr() or str() of a bool value is different from an
>     int value, some code (for example doctest-based unit tests, and
>     possibly database code that relies on things like "%s" % truth)
>     may fail.  How much of a backwards compatibility problem this will
>     be, I don't know.  If we this turns out to be a real problem, we
>     could changes the rules so that str() of a bool returns "0" or
>     "1", while repr() of a bool still returns "False" or "True".

Where is the backward compatibility problem for using bool?  At present,
no one uses it, so none of their types will be bools (right?).  Even if
they happen to use the values True and False (or whatever gets adopted),
those can be overridden just like None, so if they define and use them
they should get their values, not Python's.  Right?

>     It has been suggested that, in order to satisfy user expectations,
>     for every x that is considered true in a Boolean context, the
>     expression x == True should be true, and likewise if x is
>     considered false, x == False should be true.

I agree with your assessment; I don't agree at all with this suggestion.
6 is not equal to True, even if 6 when converted to a bool is a True. 
Python doesn't do (and shouldn't do) this kind of implicit conversion,
so the objection does not follow.

-- 
 Erik Max Francis / max at alcyone.com / http://www.alcyone.com/max/
 __ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE
/  \ Nationalism is an infantile sickness.
\__/ Albert Einstein
    Alcyone Systems' Daily Planet / http://www.alcyone.com/planet.html
 A new, virtual planet, every day.