PEP 285: Adding a bool type

[Gonçalo Rodrigues]

On Sat, 30 Mar 2002 00:39:10 -0500, Guido van Rossum <guido at python.org>
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.
>
>A long discussion has already been held in python-dev about this PEP;
>most things you could bring up have already been brought up there.
>The head of the thread there is:
>
>    http://mail.python.org/pipermail/python-dev/2002-March/020750.html
>
>I believe that the review questions listed near the beginning of the
>PEP are the main unresolved issues from that discussion.
>
>This PEP is also on the web, of course, at:
>
>    http://python.org/peps/pep-0285.html
>
>If you prefer to look at code, here's a reasonably complete
>implementation (in C; it may be slightly out of date relative to the
>current CVS):
>
>    http://python.org/sf/528022
>
>--Guido van Rossum (home page: http://www.python.org/~guido/)
>
>PEP: 285
>Title: Adding a bool type
>Version: $Revision: 1.12 $
>Last-Modified: $Date: 2002/03/30 05:37:02 $
>Author: guido at python.org (Guido van Rossum)
>Status: Draft
>Type: Standards Track
>Created: 8-Mar-2002
>Python-Version: 2.3
>Post-History: 8-Mar-2002, 30-Mar-2002
>
>
>Abstract
>
>    This PEP proposes the introduction of a new built-in type, bool,
>    with two constants, False and True.  The bool type would be a
>    straightforward subtype (in C) of the int type, and the values
>    False and True would behave like 0 and 1 in most respects (for
>    example, False==0 and True==1 would be true) except repr() and
>    str().  All built-in operations that conceptually return a Boolean
>    result will be changed to return False or True instead of 0 or 1;
>    for example, comparisons, the "not" operator, and predicates like
>    isinstance().
>
>
>Review
>
>    Dear reviewers:
>
>    I'm particularly interested in hearing your opinion about the
>    following three issues:
>
>    1) Should this PEP be accepted at all.

-0 on this. Generally, I think having a bool type is a Good Thing, but
the problem is that Python is already in version 2.2 and lots of code
has been written. So, in order to preserve backwards-compatibility some
choices have to be made. The real damage lies in

A) True == 1

The integer 1 and the boolean value True are distinct things. They
belong to different universes and as such they should have different
types => Asking if True is equal to 1 is just nonsense. A side-effect of
this is that Boolean arithmetic (that is, the +, *, etc. operations when
viewing the boolean algebra {0, 1} as the order 2 field) cannot be
implemented, e.g. True + True should be False yet because of A) this
cannot be, or else we'd get False == 2.

In fact, now that I think of it, in no circumstance we can have Boolean
arithmetic + the requisite that

B) True + 1 = 2

and such similar things (e.g. via __add__ and __radd__ checking for the
presence of integers in their arguments and making an implicit cast of
bool into int) Because in this case the expression

True + True + 1

is ambiguous (it depends on the parenthesation). And since B) is the
more important, boolean arithmetic is gone with the wind. This leaves me
uneasy.

Anyway, what we end up with is half-a-boolean, an integer in disguise.
Is it really worth adding extra baggage - and all the ensuing confusion
- for the few perceivable gains? I think not.

What I think it might be useful is to make a full blown bool type in a
module for those that need it.

My 2 cents on the subject, anyway.

Best regards,
Gonçalo Rodrigues