PEP 285: Adding a bool type

[Paul Rubin]

Guido van Rossum <guido at python.org> writes:
>     Dear reviewers:
> 
>     I'm particularly interested in hearing your opinion about the
>     following three issues:
> 
>     1) Should this PEP be accepted at all.

I don't see much need for it.  There's no need to turn Python into Java.
Python, C, and Lisp have all done fine without bools.  What kinds of
programming tasks in Python are bools supposed to make easier?

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

Again, most of those libraries have C interfaces and (pre-C99) C
didn't have bools.  I could imagine adding some kind of bool objects
in a loadable class for purposes like this, but don't see a need for
them to pervade the language.  Enums or symbols would be more useful
than bools.

>     Here are some arguments derived from teaching Python.  When
>     showing people comparison operators etc. in the interactive shell,
>     I think this is a bit ugly:
> 
>         >>> a = 13
>         >>> b = 12
>         >>> a > b
>         1

Nah, if there's one thing everyone knows about computers, it's that
they use 1's and 0's to represent truth values.

>     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.  If ints are not (normally) used for Booleans results, this
>     would stand out much more clearly as something completely
>     different.

If cmp returns a boolean, it can no longer distinguish the 3 cases
a < b, a == b, or a > b.  That is seriously broken.