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 >>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). > That's such a well-used (even though sometime abused) Ptyhon idiom that it's never going to go away.
regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://holdenweb.blogspot.com Recent Ramblings http://del.icio.us/steve.holden -- http://mail.python.org/mailman/listinfo/python-list
