Strange PEP8 recommendation on comparing Boolean values to True or False
The simplest reason to not compare truth via ==
or !=
comparisons seems to be this:
0 is False # Result: False
0 == False # Result: True; 0 evaluates comparatively to False
1 is True # Result: False
1 == True # Result: True; 1 evaluates comparatively to True
is
checks whether the value passed is exactly True
/False
, not whether it evaluates to True
or False
.
This behavior allows this:
if var is False:
# False (bool) case
elif var is None:
# None case
elif var == 0:
# integer 0 case
whereas
if var == False:
# catches False & 0 case; but not None case, empty string case, etc.
which seems counter-intuitive -- which is why I expect PEP 8 says "don't do it".
As said here use is
for identity, but use ==
for equality.
You'd only want to use if var is True
when you need the bool value True
, but want to reject 1
, 'some string'
, etc.
Such cases are probably not obvious to most readers; I suspect PEP 8 claims it's "Worse" for being potentially misleading. From time to time it may be a necessary evil; but... if you find yourself needing is True
, it may be indicating a design issue. In any case, you should probably comment "why" you need exactly True
or False
if you do ever use is
.
I believe you're reading it wrong. Try not to think of greeting
as a noun so much as a verb ("I am greeting" instead of "This is a greeting").
You can see the clue in the preamble to PEP8:
One of Guido's key insights is that code is read much more often than it is written. The guidelines provided here are intended to improve the readability of code.
To that end, code should resemble the written or spoken word as much as possible. You don't say "If I am annoying you is true, let me know"
in real life, you just say "If I am annoying you, let me know"
.
That's one reason why you tend to see boolean variables like isOpen
and hasBeenProcessed
a lot since they aid in readability of the code.
You should never do something like:
if (isOpen == True)
or:
if (customerDead == False)
simply because you already have a boolean value in the variable name. All the equality is giving you is another boolean value and, invoking reduction ad absurdum, where would you stop?
if (isComplete == True) ...
if ((isComplete == True) == True) ...
if (((isComplete == True) == True) == True) ...
if ((((isComplete == True) == True) == True) == True)...