True inconsistency in Python

[KefX]

>Yes.  The same cascade into insanity developes.  If you're testing for
>falsity, why not write x == false?  But what about _that_ test,
>shouldn't that be (x == false) != false?  And _that_ test ...
>

Of course the point that those tests aren't any less redundant from the
language perspective is valid. But they're a heck of a lot more redundant to a
human reader than a single "== false".

>My point is that any such coding standard is dumb.

In my experience, every coding standard has things one would call "dumb". But
not everybody calls the same thing dumb. (I remember some people objecting to
my assertion that "assert" should be used as often to check parameters in C
code when defining functions...I still don't get how that's dumb. Some even
claimed that assert was a C++ thing!)

>> But if whatever goes in "blah" is really long (and often it is), you
>> very
>> quickly see what is being compared: it's a straight boolean
>> comparison, whereas
>> with the second you have to look at the whole thing, find no
>> comparison
>> operator, and go, "oh, there's no explicit comparison so it's
>> obviously an
>> implicit straight boolean comparison".
>
>I don't see the value in this.  The expression in an if statement is
>treated as a Boolean expression.  In languages where there isn't a
>distinct Boolean type without implicit conversions (like your example,
>C89), it doesn't matter whether you put the explicit comparison there or
>not. However long the expression is, I don't see how adding `== true'
>at the end makes it more clear.

What if the expression is 37 lines long? (Can't happen? I'm LOOKING at such an
example!) Fishing out the main comparison in such a monster isn't always the
easiest thing to do. Of course I'm exaggerating here, since we usually don't
write 37-line expressions, but still.

>It's a Boolean test, what's to make
>explicit?

Yes, all tests are boolean tests in the sense that they evaluate to a bool and
the if statement then compares the result, but not all comparisons are boolean
comparisons in the sense that we don't always compare to a boolean value. In
other words, "a == 0" isn't comparing against true or false, it's comparing
against an integer. It's worth noting here that omitting the "== 0" here is
considered bad style by many (though this is by no means universal). The camp
that would have you write "== false" invariably falls in the same camp that
would have you write "== 0", because that way the two would be consistent in
that you always specify what's being compared to what. Of course, this doesn't
mean everybody would have you write "== 0" would also have you write "==
false". The idea is consistency (I don't know how that slipped my mind in my
original posting.)

>All including the explicit test there does is make other programmers
>wonder if you've lost your mind

Not all programmers would think that, again. :)

>Trying to correct that error, you end up with monstrosities such
>as bool(x) == True or operator.truth(x) == True (or the equivalent in
>other languages), and after some point it should dawn on the programmer
>that the explicit True test is pointless.

I don't see how that would logically follow just from making an explicit bool
test. We know that such code is broken when we consider it, and then we reject
it, and we just do it the way we always did it, whether that's omitting the
explicit comparison altogether or comparing against false, or whatever other
possibility.

- Kef