On 08/08/2012 09:23 PM, Ben Finney wrote:> Rob Cliffe <rob.cliffe@btinternet.com> writes:
>[...]
>>     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.