[Python-Dev] Re: PEP 285: Adding a bool type (original) (raw)

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