[Python-Dev] Mixing float and Decimal -- thread reboot

[Raymond Hettinger]

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