On 08/08/2012 09:23 PM, Ben Finney wrote:> Rob Cliffe
[...]
2) Say you are writing a function to process an arbitrary object,
e.g.
a custom version of repr. You might well choose to write if obj is True: # processing elif obj is False: # processing elif type(obj) is int: # processing
Again, this is much clearer written as:
if type(obj) is bool: # processing if type(obj) is int: # processing
So not a compelling use case for checking specific values.
Your replacement is not equivalent. I think what you meant was, if type(obj) is bool: if obj: # processing else: # processing elif type(obj) is int: # processing I don't find that clearer at all, let alone "much clearer" than, if obj is True: # processing elif obj is False: # processing elif type(obj) is int: # processing (On the other hand I wouldn't claim the latter is "much clearer" than the former either, but your claim is wrong IMO.)
[...] On the other hand, ‘if foo is True’ is a common beginner mistake that we meet frequently in ‘comp.lang.python’, and is almost always better written as ‘if foo’. It's that kind of advice that belongs in PEP 8.
Perhaps correcting beginner's mistakes should be done in the tutorial while PEP-8 should be aimed at a broader and on average more advanced audience. I realize that one purpose of style conventions are to avoid mistakes, including beginner one's but I and several times found the simplest, most intuitive way to implement tri-value logic was to use {True, False, None} and so think that if "is True" is to be officially discouraged because misuse by some people in the first .5% of their Python careers, the reason for that discouragement should at least be explained in PEP-8.