On May 15, 12:30 am, "Gabriel Genellina" <[EMAIL PROTECTED]>
wrote:
> 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.
Except when they aren't.
>>> import gmpy
>>> a = 2**177149-1
>>> b = gmpy.mpz(2**177149-1)
>>> a==b
True
>>> print '%d' % (b)
Traceback (most recent call last):
File "<pyshell#4>", line 1, in <module>
print '%d' % (b)
TypeError: int argument required
So although the comparison operator is smart enough to realize
the equivalency of numeric types and do the type conversion,
the print statement isn't so smart.
> 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,
I didn't say that, I said the performance issues were related
to type conversion. Can you explain how the "definition" of
equal does not involve type conversion?
> only with how someone decided to write the mpz class.
I'm beginning to think there's a problem there.
>
> --
> Gabriel Genellina
--
http://mail.python.org/mailman/listinfo/python-list
