PEP 285: Adding a bool type

[Guido van Rossum]

Someone wrote:

> It's a cost/benefit thing.  Type/class unification may have cost more
> in complexity than bools cost, but it has high benefits.  The bool
> thing would a complicated change with limited benefit, so it's provoked
> some sharp reactions.

That's an interesting response, because it highlights what I think is
the main misunderstanding about the PEP.  You should think of it a
very *small* change!

Some operations that conceptually return a truth value (like a==b)
have to pick something to represent that result.  This is only needed
when no other object among the operation's arguments is suitable to
represent the result, for example in "not x".  While almost any value
is usable to express a truth value, traditionally the Python core and
standard library have consistently picked 0 to represent falsehood
and 1 for truth.

A problem with this is that the intention isn't always clear.  Does a
particular 1 represents a specific count or is it simply a
representative of truth?  While ultimately this is a matter of
documentation, having a notation helps clarify the matter (in cases
where it is used).

To solve the problem of clarifying intent, the PEP introduces two new
values that the core will use in preference over 0 and 1, and standard
names for them.  It makes them the only values of a new type, so that
they can be recognized as the canonical representatives when
necessary.  For backwards compatibility, these values act just like
the integers 0 and 1 in non-Boolean contexts (except when printed or
converted to a string).  For simplicity of implementation, and to
guarantee backwards compatibility at the C level, the new type is
implemented as a subtype of the built-in int type.

No user code needs to be changed unless it is sensitive to the string
representation of Python objects.  There is no prejudice against user
code that continues to use 0 and 1 (or something else) to represent
truth values.

In order to give people coming from (or going to) other languages an
easy time getting used to the new type, it is called bool, and its
values are called False and True.  But like so many things in
Python[*], its bool type acts slightly different than the Boolean type
in other languages.  That's fine -- other languages don't all agree on
the details of Boolean types anyway, varying from very strict (Pascal,
Java) to very loose (C, Lisp).

This is long enough of a response.  To those people who complain that
I don't take their long thoughts seriously, I can only respond that I
thought long and hard about this PEP too, and am similarly disappointed
that it faces so much opposition based upon what *might* happen.

--Guido van Rossum (home page: http://www.python.org/~guido/)

[*] Take variables for example.  You can write "x = 1" in Python just
as in C or Perl, and superficially it does the same thing.  But the
meaning is profoundly different!  1 is an object, and x is a name
binding for that object.  This goes on in Python all the time: other
examples are x+y, for loops, even function argument default values.
Booleans have their own twists and always had ("if x", "x and y").
Python is not unique here either -- many language have different
semantics underneath familiar notations, and this can represent a real
breakthrough (like Smalltalk, which redefined x+y as sending the
message "+y" to the object x).