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

Gerald S. Williams gsw@agere.com
Mon, 1 Apr 2002 08:55:13 -0500

Guido van Rossum wrote:
> I offer the following PEP for review by the community.  If it receives
> a favorable response, it will be implemented in Python 2.3.

I like almost all of it as written.

>     2) Should str(True) return "True" or "1": "1" might reduce
>        backwards compatibility problems, but looks strange to me.

I also prefer "True". int(True) returns 1 if you need it.

>     3) Should the constants be called 'True' and 'False'

I prefer "True" here also (this is Python, not C).

>     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).  Personally,
>        I think we shouldn't; 28+isleap(y) seems totally reasonable to
>        me.

No need. It is only equivalence operations that cause problems.

>     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.  This is of course
>     impossible; it would mean that e.g. 6 == True and 7 == True, from
>     which one could infer 6 == 7.  Similarly, [] == False == None
>     would be true, and one could infer [] == None, which is not the
>     case.  I'm not sure where this suggestion came from; it was made
>     several times during the first review period.  For truth testing
>     of a value, one should use "if", e.g. "if x: print 'Yes'", not
>     comparison to a truth value; "if x == True: print 'Yes'" is not
>     only wrong, it is also strangely redundant.

I (was at least one of the people who) brought this up.

Without getting tied up in the discussion about which
should inherit from which: in boolean context, 6 == 7 and
[] == None. This does not imply that they are equivalent

The problem is the equivalence test itself. It may be true
that "if x == True:" is redundant, in which case you may
want to disallow such comparisons. But performing an integer
comparison will confuse perfectly rational people at least
some of the time.

Consider that the main source of confusion won't come from
comparisons to True, but comparisons to False. These two
statements might look identical to the casual observer, but
they really aren't:

  if not expr:

  if expr == False:

I think *that* is probably the best way to summarize my


-O Gerald S. Williams, 22Y-103GA : mailto:gsw@agere.com O-
-O AGERE SYSTEMS, 555 UNION BLVD : office:610-712-8661  O-
-O ALLENTOWN, PA, USA 18109-3286 : mobile:908-672-7592  O-