Re: Interesting list Validity (True/False)

On May 15, 12:30 am, "Gabriel Genellina" <gagsl-...@xxxxxxxxxxxx>
wrote:
En Tue, 15 May 2007 01:37:07 -0300, mensana...@xxxxxxx
<mensana...@xxxxxxx> 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


.

Relevant Pages

  • Re: Interesting list Validity (True/False)
    ... different string types, never compare equal; ... there is no explicit type test. ... of shoes is not the same as a box of shoes, even if they are the same ... numeric types, so the earlier rule applies: ...
    (comp.lang.python)
  • Re: Interesting list Validity (True/False)
    ... except different numeric types and ... different string types, never compare equal; ... "a list is a boolean"? ... they both have a 1 at index position 0? ...
    (comp.lang.python)
  • Re: Interesting list Validity (True/False)
    ... That sounds nonsensical and incorrect. ... except different numeric types and ... different string types, never compare equal; ...
    (comp.lang.python)
  • Re: comparison with None
    ... Library reference, 3.3 Comparisons ... "Objects of different types, except different numeric types and different string types, never compare equal; such objects are ordered consistently but arbitrarily." ... Gabriel Genellina ...
    (comp.lang.python)