pep8 minor annoyance

Question

In /tmp/spam.py:

n = 69

if n == True:
    print 'potato'

pep8 utility complains about this conditional:

wim@SDFA100461C:/tmp$ pep8 spam.py 
spam.py:3:6: E712 comparison to True should be 'if cond is True:' or 'if cond:'

• the first suggestion is wrong/"worse" according to pep8 itself
• the second suggestion changes the behaviour of the code

What is the best practice for a case where you actually do want to check equality with True? Is identity checking with True using is OK? Why does pep8 utility offer an alternative which is explicitly discouraged in pep8 itself?

Answer 1

If you really do need to check equality with True then use == and ignore PEP8, but in almost any conceivable case that isn't what you want.

If you want to know whether the value you have is one of the values Python considers to be true, use if cond:. If you want to know whether the value you have is the singleton value True then use is True, the booleans True and False are singletons so it is correct to use is in this situation.

If you need to test whether your object is the singleton True, but a linter or a code reviewer complains about is True, then isinstance(x, bool) and x is a behaviorally equivalent (but slower) substitute.

Checking x == True is a halfway house. It is true when x is True is true, and false for your case of x=69, but there are other objects which are not themselves True but for which x==True gives an unexpectedly true result such as 1 == True being true. (thanks @Ant).

So putting that together:

value of n:    True  1     69     False   0
-----------------------------------------------
expression     result
-----------------------------------------------
if n:          True  True  True   False   False
if n is True:  True  False False  False   False
if n==True:    True  True  False  False   False

Pick the row from that table which gives the results you really wanted (and the last one isn't it).

Answer 2

Whatever you do, I think a comment is required since the code looks funny.

If you want to check equality with True then it might be clearer to write if n == 1. Someone reading the code is less likely to misinterpret it as an attempt to test logical truth.

Of course if n has a user-defined type it's possible to define n.__eq__ such that (n == True) != (n == 1), but it would be pretty nasty. So you'd have to decide whether the subtle difference in meaning is justified by the benefit of avoiding the code looking like an incorrect logical truth test.

If the difference is not justified, and if you're absolutely required to write to the PEP8 style guide, then either use assertEqual or write expected_value = True, if n == expected_value.

If the code is a unit test for an API that for some reason defines specifically that the literal True is returned, then of course you should test if n is True, not if n == True. As before, a comment or some indirection would be needed to stop the code looking wrong.

Another option is to change the API you're testing. The reason for the style guide rules is in part to discourage people from inventing or relying on APIs that specifically define that the return value must be identical or equal to the literal True, and instead define APIs and write their code in terms of logical truth. So if you "fix" the API you can "fix" the code that tests it.

Answer 3

Why do you need to explicitly test for True values? You rarely, if ever do need narrow your test down to a specific type. I'd rethink your use case here; if you are building an API that'll return a bool instead of in int for out-of-band conditions, then use exceptions instead.

If you do have to test for True only, then use

if n is True:

because the boolean values are meant to be singletons like None. See the Programming recommendations section:

Comparisons to singletons like None should always be done with is or is not, never the equality operators.

Moreover, because issubtype(bool, int) is true (for historical reasons; bool was introduced rather late in Python), n == True is also true for n = 1, if you can only accept True here then you can only use is True. You could also use isinstance(n, bool) and n, which would allow for subclasses of bool, but I cannot imagine there ever be a use for such a type, and in current implementations, bool explicitly prohibits being subclassed.

The PEP 8 rule about using not using if cond is True: is specifically called out because it limits the value of cond to the bool only.

Last but not least, PEP 8 starts with this:

A Foolish Consistency is the Hobgoblin of Little Minds

[...] But most importantly: know when to be inconsistent -- sometimes the style guide just doesn't apply. When in doubt, use your best judgment. Look at other examples and decide what looks best.

Only follow PEP 8 if it suits your needs.

Answer 4

The second recommendation would best suit your needs. The conditional statement if cond: will return true if the condition itself is true. It will not change the behavior of the code, as it is just shorthand for if cond == True:.