ACCEPTED: PEP 285

[Terry Reedy]

"Guido van Rossum" <guido at python.org> wrote in message
news:mailman.1017873312.18135.python-list at python.org...
>     7) Should the name 'bool' be changed?
>     => No.
>        One reviewer has argued to make the name 'truth'.  I find
this
>        an unattractive name, and would actually prefer to reserve
this
>        term (in documentation) for the more abstract concept of
truth
>        values that already exists in Python.  For example: "when a
>        container is interpreted as a truth value, an empty container
>        is considered false and a non-empty one is considered true."

Especially since reading Laura's essay, I no longer consider that to
be the proper term.  'Truth' is only one model for dichotomy, which is
the proper generic descriptive term, but which is too long to use as
is and not gracefully abbreviated.  I thought of suggesting 'bit', but
that falsely implies a length of 1, even though a significant bit
difference of one is true.  I can see +s and -s to every name I have
considered, including bool.

> Clarification
>
>     This PEP does *not* change the fact that almost all object types
>     can be used as truth values.  For example, when used in an if
>     statement, an empty list is false and a non-empty one is true;
>     this does not change and there is no plan to ever change this.

almost? all?  I am under the impression that 'if x:' is universally
valid, and consider that one of the good features of Python's prime
dichotomy system.

>     The only thing that changes is the preferred values to represent
>     truth values when returned or assigned explicitly.  Previously,
>     these preferred truth values were 0 and 1; the PEP changes the
>     preferred values to False and True, and changes built-in
>     operations to return these preferred values.

I consider the change to be a change of hat (type) rather than a
change of value, just as I and Python consider 1 and 1L to be two
different guises for the same value.

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

Python's nothing/something dichotomy divides all(?) Python objects
into two equivalence classes.  As is typical in mathematics, we choose
one member of each, 0/False and 1/True, as (canonical)
representatives.  It is not sensible to expect members of a class to
equal the chosen representative (except in relation to the
class-defining attribute).  People should really learn this much of
class logic.  If explained this way, I would hope that such
expectations would vanish.

Terry J. Reedy