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