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

Guido van Rossum guido at python.org
Wed Mar 24 23:23:11 CET 2010


On Wed, Mar 24, 2010 at 2:29 PM, Raymond Hettinger
<raymond.hettinger at gmail.com> wrote:
>
> 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.

That's how I read the PEP too. PEP 3141 doesn't define any ordering
operations on Complex, they only show up on Real.

> To confirm, we should ask Jeffrey Y to opine.

CC'ed him. After all looks like it was he who added it to Fraction. :-)

-- 
--Guido van Rossum (python.org/~guido)


More information about the Python-Dev mailing list