PEP 285: Adding a bool type

[Terry Reedy]

"Guido van Rossum" <guido at python.org> wrote in message
news:mailman.1017466974.6751.python-list 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.

>     1) Should this PEP be accepted at all.

+0.8 -- as long as it is not a first step in de-arithmetizing truth
values.

Proposed amendment: call the new type 'truth' instead of 'bool' and
change the title of the PEP to "Formalizing a Python truth type".

A. This PEP formalizes existing Python practice in regards to truth
values.  The 'new' type is not really new.  The main visible effect is
to change the display of the doubleton values.  The existing magic
method is __truth__().  Better to call the new type and constructor
truth() than to change __truth__ () to __bool__().

B. 'bool' is an abbreviation of Boolean, the adjectival form of Boole,
an English mathematician.  I agree with the philosophical argument for
nomenclature that is descriptive rather than 'nymic' (named after
persons -- I forget the formal linguistic term for such).  All other
Python terms that I can think of (except for the name Python itself)
follow this sensible principle.  To me, naming one particular type
after a person is somewhat jarring, especially when it is not
necessary.

C. Anyone learning Python has some idea of truth and truth values.
But I am sure there are some with no idea of what 'bool' means and
only a vague idea about 'Boolean'.  Better formalizing Python truth
values should make them even easier to learn; why not call them what
they are?

D. The word bool(ean) carries a lot of baggage in terms of expected
behavior and *limitations* on behavior.  At least half the debate on
this PEP revolves around the fact that Python truth values act
differently from 'proper' boolean values.  The title of this PEP,
"Adding a bool type", is arguably misleading since the newly
formalized type will not be boolean as many understand the term.

If we do not call Python truth values what they are not quite, or
rather what they are more than, we avoid the mismatch between
expectation and reality (and years of requests to change reality to
match expectation).  In other words, the critics are partly right;
however, my solution is to drop the slightly misleading word bool (and
its associated baggage) instead of changing current (and proposed)
behavior (which I think is pretty good).

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

I can see it either way.

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

+ 1 for True/False to corresponding to None, etc.  Do true/false work
*exactly* the same way in all three other languages?  Will Python
True/False be exactly the same?  (I suspect not but simply do not
know.)

>     True+1 == 2 must hold, else reams of existing code would break.

yes, yes, yes.  While this may not be 'proper' boolean behaviour, it
is current Python truth value behaviour.

>     4) Should we strive to eliminate non-Boolean operations on bools
>        in the future, through suitable warnings, so that e.g. True+1
>        would eventually (e.g. in Python 3000 be illegal).

no, no, no.  Eliminating useful polymorohic behavior is hardly
Pythonic.

If the new type were called 'truth' (as suggested above, or  'binary')
instead of 'bool', this question would hardly arise.  The behavior of
Python truth values is, for the most part, a *superset* of some
preconceived notions of allowed 'Boolean' operations.  So what?  This
is true of any type which inherits methods from two base types (see
below).

>        I think we shouldn't; 28+isleap(y) seems totally reasonable
to me.

Forcing this and all similar constructions to be written as
'28+int(isleap(y))' gains nothing and goes against general Pythonic
polymorphism.   Why should one be able to add instances of arbitrary
user-written classes to 28 but not instances of bool/truth?

I understand OO purist objections, but Python is simply not an
OO-purity language.
Documentation makes no claim about what one 'ought' to be able to do
with instances of derived classes versus instances of super-classes.

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

I think I would find it odd as new learner to have this one 'logical'
function not return bool.

>     Note that subclassing from int means that True+1 is valid and
>     equals 2, and so on.  This is important for backwards
>     compatibility: because comparisons and so on currently return
>     integer values, there's no way of telling what uses existing
>     applications make of these values.

>     Because of backwards compatibility, the bool type lacks many
>     properties that some would like to see.

??  Because of backwards compatibility, the bool (Python truth) type
will have properties that I *want* to keep.

> For example, arithmetic operations with one or two bool arguments
> is allowed, treating False as 0 and True as 1.

suitibility = has_a(x) + is_b(x) + does_c(x)

Again, wrapping each term in int() in the service of pedantry does not
strike me as Pythonic.  Admittedly, I could define class mybool(int)
(using the reference implementation given in PEP + whatever needed to
make mixed expressions work) and have all predicates I write return
mybool instead of bool(truth).  But having to do seems worse that
present situation.

> Also, a bool may be used as a sequence index.

(option_a, option_b)[binary_switch] # can be quite useful

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

Completely agreed.  Again, these issues seem to arise from calling
Python truth values 'bool'.  Conceptually, they inherit behavior from
both int and bool (in the strict sense).

>     Another consequence of the compatibility requirement is that the
>     expression "True and 6" has the value 6, and similarly the
>     expression "False or None" has the value None.  The "and" and
"or"
>     operators are usefully defined to return the first argument that
>     determines the outcome, and this won't change; in particular,
they
>     don't force the outcome to be a bool.

Some languages use 'cand' and 'cor' to differentiate short-circuiting
'conditional'
and/or from strictly logical and/or, but I am glad Python does not.
In any case, Pythons and/or are Python truth value operators, not
Boolean operators.

About deriving bool from int:  a couple of years ago, I followed a
looooong thread on comp.object about the relationship of circles and
ellipses and which should be derived from which.  The problem for oo
theory, it seems to me, is that specialization can take place either
by addition -- a bird is a vertebrate that can fly -- or by
subtraction -- a ratite is a bird that cannot fly.  Evolution does not
follow substitutivity rules.  Neither do mathematicians and
programmers.

Terry J. Reedy