PEP 285: Adding a bool type

Tim Peters tim.one at comcast.net
Sun Mar 31 22:38:49 EST 2002


[Terry Reedy]
> ...
> My proposal has two parts: do not use 'bool'; do use 'truth' (or
> possibly something else such as 'binary' or even 'tval').  I am
> curious what you think of the four reasons I gave.  I am specifically
> curious whether you will volunteer to anwer a multiyear stream
> (already started) of questions about why Python truth values, being
> called bool, do not act 'properly' as bools 'should' and suggestion
> that they 'ought' to be restricted (crippled) so that they do.

I think this is easy:  I point them at the C99 standard, whose boolean is
very much like Guido's conception, and end with "yup, same thing in Python".
Or just point them at the PEP.  The idea that the same people are *not*
going to complain about True+1 if the type is called "binary" (or anything
else) instead isn't credible to me.  They'll insist that True+1 is evil just
because part of it is spelled "True".  If the new tval type had singleton
constants Freeble and Goroblof, people would still complain about
Goroblof+1, but not just because of the addition <wink>.

We can't stop those so inclined from complaining about True ** False - False
** True == True no matter what the type is called.

> For some (many? most?) people, it's obvious now, 'Boolean' and its
> derivative 'bool' have a definite and restricted usage that excludes
> Python truth values current and proposed.

I expect they're triggered more by True and False than by "bool".  The
boolean types in C99 and C++ play nicely with integers; Java's and Pascal's
and Fortran's don't; so it goes.

> Perhaps we should honor that usage

There's no consistency across existing computer languages, and I've got no
reason to give more weight to, say, Java's choices than to C's.  If you have
to think of it in these terms <wink>, think of it as honoring C99.

> and use something either more general or more specific to Python.
> Otherwise, we had bettter say pretty clearly that Python bool
> is not Boolean and that one should think of it as a type with dual
> inheritance from both int and (abstract, not implemented) Boolean.
> (And expect that people will be mislead anyway.)

I agree the docs need to be clear, but, still, it is what it is no matter
what it's called.





More information about the Python-list mailing list