On 11/08/12 13:47, Mike Meyer wrote:
Am I the only one that noticed this?
PEP 8 says: "Don't compare boolean values to True or False using ==."
To me, all the talk about wanting to test variables that might not hold True of False (i.e. - True/False/None or True/False/String or ...) are off topic, as those values *aren't* boolean values. So this bit of the PEP doesn't really apply to those cases.
That's debatable. If I have an object which could be True/False/Other, or even many different Others, once I've eliminated the Other case(s), I'm left with a binary choice between two bools. Hence PEP 8 apparently applies even when dealing with tri-state logic values.
Some of the responses have touched on this by saying you should check that the values are/aren't boolean before testing them, which would mean the above would apply to the tests on the boolean branch.
But the arguments are all couched in terms of better style, as opposed whether or not the this rule in the PEP actually applies.
I don't understand. The rule is a style rule, and programming style is intended to result in better code. So what's your point?
Am I wrong here? Has my exposure to Hindley-Milner type systems tainted me to the point where I just don't get it any more?
I don't anything about Hindley-Milner, but I do know that duck-typing means that any object can quack like a bool.
I also know that even in languages with strict True/False bools, like Pascal, writing "if flag == True" is a common rookie mistake.
In both cases, a recommendation to avoid both "flag == True" and "flag is True" is good advice. PEP 8 already gives us permission to break the rules when necessary. What else do we need?