En Tue, 15 May 2007 01:37:07 -0300, [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list