On Mar 24, 2010, at 2:09 PM, Mark Dickinson wrote:
Slight change of topic. I've been implementing the extra comparisons required for the Decimal type and found an anomaly while testing. Currently in py3k, order comparisons (but not ==, !=) between a complex number and another complex, float or int raise TypeError:
z = complex(0, 0) z < int() Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: unorderable types: complex() < int() z < float() Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: unorderable types: complex() < float() z < complex() Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: unorderable types: complex() < complex()
But Fraction is the odd man out: a comparison between a Fraction and a complex raises a TypeError for complex numbers with nonzero imaginary component, but returns a boolean value if the complex number has zero imaginary component:
z < Fraction() False complex(0, 1) < Fraction() Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: unorderable types: complex() < Fraction()
I'm tempted to call this Fraction behaviour a bug, but maybe it arises from the numeric integration themes of PEP 3141. Any ideas?
Conceptually, it's a bug. The numeric tower treats non-complex numbers as special cases of complex where the imaginary component is zero (that's why the non-complex types all support real/imag), and since complex numbers are not allowed to compare to themselves, they shouldn't compare to anything else either. To confirm, we should ask Jeffrey Y to opine. Raymond