PEP 285: Adding a bool type

[Chris Gonnerman]

----- Original Message ----- 
From: "Guido van Rossum" <guido at python.org>


> I offer the following PEP for review by the community.  If it receives
> a favorable response, it will be implemented in Python 2.3.
>
> ...
>
>     Dear reviewers:
> 
>     I'm particularly interested in hearing your opinion about the
>     following three issues:
> 
>     1) Should this PEP be accepted at all.

Looks cool to me.

>     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".)

"True" sounds best to me.  Explicit is better and all that...

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

Proper case is Pythonic (based on existing usage of None, exception
names, etc.)
 
> ...
> 
>     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.

bool.  If you've got it, use it.

>...
> 
>     Some external libraries (like databases and RPC packages) need to
>     be able to distinguish between Boolean and integral values, and
>     while it's usually possible to craft a solution, it would be
>     easier if the language offered a standard Boolean type.

This is a VERY good reason IMHO.

>     The standard bool type can also serve as a way to force a value to
>     be interpreted as a Boolean, which can be used to normalize
>     Boolean values.  Writing bool(x) is much clearer than "not not x"
>     and much more concise than
>         if x:
>             return 1
>         else:
>             return 0

Yes!  I LIKE it.

> ...
> 
>     There's also the issue (which I've seen puzzling even experienced
>     Pythonistas who had been away from the language for a while) that if
>     you see:
> 
>         >>> cmp(a, b)
>         1
>         >>> cmp(a, a)
>         0
>         >>> 
> 
>     you might be tempted to believe that cmp() also returned a truth
>     value.

This one bit me in the early days.

> ...
> 
>     I don't see this as a problem, and I don't want evolve the
>     language in this direction either; I don't believe that a stricter
>     interpretation of "Booleanness" makes the language any clearer.

Ditto.  "Language clarity" has been thrown around as a reason for all
kinds of much more invasive enhancements.  Python IS clear, and *very*
few constructs borrowed from other languages are going to improve it 
now.  Just two reserved words, True and False, in proper case, are not
going to break much and just might add some of the clarity that everyone
seems to want to add.
 
Chris Gonnerman -- chris.gonnerman at newcenturycomputers.net
http://newcenturycomputers.net