question about True values

[John Coleman]

Martin v. Löwis wrote:
> John Coleman schrieb:
> > Yes - it just seems that there isn't a principled reason for implicitly
> > converting 3 to 3.0 in 3.0 == 3 but not implicitly converting "cat" to
> > boolean in "cat" == true.
>
> Sure there is: equality should be transitive. So while we have
> 3 == 3L == 3.0 == 3.0+0j
> and can therefore imply that 3 == 3.0+0j, we should not get
> 5 == True == ["foo"]
> and therefore imply that 5 == ["foo"].
>
> The phenomenon really exists only for numeric types (that two
> values of different types still represent the same "thing"),
> so it's not surprising that this doesn't readily extend to
> other types.
>
> In Python, there are only very few similar cases: byte strings
> and unicode strings sometimes compare equal (but, since 2.5,
> don't compare unequal very often); lists and tuples could be
> considered to have equal values, but don't actually do compare
> equal.
>
> Regards,
> Martin

Very good point, though one could argue perhaps that when one is
comparing an object with a truth value then one is implicitly asking
for the truth value of that object i.e. how it would function if used
in an if statement, etc. This would make code like 'if s: ' equivalent
to 'if s == True:' with a possible gain in readability. But - as you
demonstrate the cost of that (minimal) gain in readability would be too
high. In any event - I think it is mostly bad style to use a
non-boolean variable in 'if s:' - it reminds me too much of obscure C
code (though others might disagree).

-John Coleman