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

Barry A. Warsaw barry@zope.com
Wed, 3 Apr 2002 11:35:38 -0500


>>>>> "AK" == Andrew Koenig <ark@research.att.com> writes:

    AK> Specifically: If I want to write a function that answers a
    AK> yes/no question, I have lots of possible ways of spelling yes
    AK> (1, 2, "yes", and so on) and lots of possible ways of spelling
    AK> no (0, {}, None, and so on).  There isn't a single preferred
    AK> way.

This is a strong pro (IMO) for PEP 285.  When I code a flag, do I use
0 and 1, or None and 1, or ...what?  When you see code that says
"x.isthing = 1" what does that tell you about how this attribute will
be used?  I like the bool because it provides clarity when coding flag
values, and you still maintain the (IMHO beautiful) feature of being
able to say "this variable has a value, or it's never been set".
I.e. flag=None, flag=True, flag=False.

The strongest con for PEP 285 seems to be the natural inclination for
people to want to write "if cond == True:".  Heck, /I/ certainly wrote
that the first time I thought about bools years ago (and even made
that "work" in my early pure-Python prototypes).  But it doesn't make
sense since "if cond:" and "if not cond:" are better than comparison
against the boolean constants.

There's two reasons we teased out about why people may tend to
want to compare against True and False.  People may think that the
comparison is somehow part of the syntax of the if statement.  Also,
using the comparison can sometimes be more aligned with English
grammar.  E.g. this reads well on its own:

    if year.isLeapYear():

Note the use of `is' which tends to be a common prefix on predicates.
But if you don't use that prefix, then you are maybe inclined to add
the test:

    if flag == True:

so that it reads somewhat like "if flag is True".  (Why don't we tend
to write exactly that?  Maybe because as Python programmers, we're
trained not to use identity tests except in very limited situations?).

-Barry