Interesting list Validity (True/False)

[mensanator at aol.com]

On May 15, 12:30 am, "Gabriel Genellina" <gagsl-... at yahoo.com.ar>
wrote:
> En Tue, 15 May 2007 01:37:07 -0300, mensana... at aol.com  
> <mensana... 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.

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