I'd be strongly against changing that rule. If you don't want other types than bool, use an isinstance check. Code using "is True" is most likely a bug. (It's different for None, since that has no second value that is assumed.)

--Guido

On Wednesday, August 8, 2012, Michael Foord wrote:
Hey all,

True and False are singletons, so if you want to check precisely for True and False then an identity check seems appropriate. 

However the "Programming Recommendations" section of PEP 8 has this to say on the topic:

Don't compare boolean values to True or False using ==.

Yes:   if greeting:
No:    if greeting == True:
Worse: if greeting is True:

http://www.python.org/dev/peps/pep-0008/#programming-recommendations

It seems to me that there is an important distinction between testing that an object is either the boolean True or False and merely checking the "truthiness" of an object. Many a bug has been caused by an empty container object (or some other falsey object) falling into an "if not value" clause that was actually meant to check for the presence of False or None.

Why does PEP 8 recommend not testing "boolean values" (which to me implies "values you expect to be a bool") using equality or identity, and more specifically why does it say that using an identity check is worse than an equality check?

As this is Python-ideas and not python-list, my specific suggestion is to modify the wording of that section - or just removing it altogether as I don't think it can be adequately clarified without using lots of words.

All the best,

Michael Foord

--
http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html



--
--Guido van Rossum (python.org/~guido)