Interesting list Validity (True/False)

Gabriel Genellina gagsl-py2 at yahoo.com.ar
Tue May 15 01:30:26 EDT 2007


En Tue, 15 May 2007 01:37:07 -0300, mensanator at aol.com  
<mensanator at aol.com> escribió:

>> > <quote emphasis added>
>> > Sec 2.2.3:
>> > Objects of different types, *--->except<---* different numeric types
>> > and different string types, never compare equal;
>> > </quote>
>>
>> The exceptions you mean are not exceptions to "'X==Y' means 'X equals
>> Y'".
>
> I never said they were. I said they were exceptions to
> "Obbjects of different types never compare equal".

This is an unfortunate wording, and perhaps should read: "For most builtin  
types, objects of different types never compare equal; such objects are  
ordered consistently but arbitrarily (so that sorting a heterogeneous  
sequence yields a consistent result). The exceptions being different  
numeric types and different string types, that have a special treatment;  
see section 5.9 in the Reference Manual for details."

And said section 5.9 should be updated too: "The objects need not have the  
same type. If both are numbers or strings, they are converted to a common  
type. Otherwise, objects of different builtin types always compare  
unequal, and are ordered consistently but arbitrarily. You can control  
comparison behavior of objects of non-builtin types by defining a __cmp__  
method or rich comparison methods like __gt__, described in section 3.4."

I hope this helps a bit. Your performance issues don't have to do with the  
*definition* of equal or not equal, only with how someone decided to write  
the mpz class.

-- 
Gabriel Genellina




More information about the Python-list mailing list