[Python-Dev] Re: PEP 285: Adding a bool type

[Guido van Rossum]

> The addition of another type really does change the set of preferred
> truth values from {0, 1} to {0, False, 1, True}.  The typical
> practicing Python programmer who wants to say "true" would have to
> decide -- for each instance -- whether to say "1" or "True".

No.  If they want to use the *recommended* values they should always
use False or True.  0 and 1 are relegated to the domain of
non-representative values of the set of false and true objects, just
as None and "true" (the string literal).

> And the programmer cannot happily ignore the issue and stick to
> using 0 and 1, because if comparisons start to return True and
> False, dealing with a mix of four truth values is unavoidable.  This
> PEP makes me uneasy because it causes me to see lots of extra casts
> in Python's future (not to mention confused beginners).

You misunderstand it.  Strings, lists, numbers and so on are still
acceptable as truth values, and when you want to know whether x is
true or false, you still have to say "if x:" -- never "if x == True:".

In addition, for backward compatibility 0 == False and 1 == True, so
mixing them shouldn't be a problem if you know your values are
chosen from the set {0, False, 1, True}.

If you find yourself comparing an unknown value x to a known truth
value to determine whether x is true or false, stop right there:
you've *already* got a problem.  If you don't have a problem because
it works in practice (meaning x is known to be 0 or 1) the backwards
compatibility of the PEP kicks in and saves your butt.  This won't
be deprecated: the PEP promises that False==0 and True==1 will always
hold.  (There's a question for reviewers about this, but consider it
decided -- bools will always mix freely with ints.)

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