question about True values

Steve Holden steve at
Thu Oct 26 01:07:50 CEST 2006

John Coleman wrote:
> 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
> 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).
That's such a well-used (even though sometime abused) Ptyhon idiom that 
it's never going to go away.

Steve Holden       +44 150 684 7255  +1 800 494 3119
Holden Web LLC/Ltd
Skype: holdenweb
Recent Ramblings

More information about the Python-list mailing list