[Python-Dev] Decimal & amp; lt; -& amp; gt; float comparisons in py3k.

Mark Dickinson dickinsm at gmail.com
Fri Mar 19 20:50:38 CET 2010


On Fri, Mar 19, 2010 at 6:43 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> On 3/19/2010 2:11 PM, Antoine Pitrou wrote:
>>
>> Raymond Hettinger<raymond.hettinger<at>  gmail.com>  writes:
>>>
>>> The reason to prefer an exception is that decimal/float comparisons
>>> are more likely to be a programmer error than an intended behavior.
>
> If you really believe that, then equality comparisons should also be
> disabled by raising NotImplemented or whatever.

Hah.  This is a very good point, and one I'd somehow missed up until
now.  I don't think we *can* reasonably make equality comparisons
raise NotImplemented (in either 2.x or 3.x), since that messes up
containment tests:  something like "1.0 in {2, Decimal(3)}" would
raise a TypeError instead of correctly returning False.  (So the patch
I've put on the issue tracker is wrong, since it does raise TypeError
for equality and inequality, as well as for <, >, <= and >=.)

> Clearly, someone who writes
> 'if somefloat == somedecimal:'assumes (now wrongly) that the test might be
> true. This is just as buggy as an order comparison. Raising an exception
> would consistently isolate decimals from other numbers and eliminate the
> equality intransitivity mess and its nasty effect on sets.
>
> It still strikes me as a bit crazy for Python to say that 0.0 == 0 and 0 ==
> Decimal(0) but that 0.0 != Decimal(0). Who would expect such a thing?

Agreed.  A solution to the original problem that still has 0.0 ==
Decimal(0) evaluating to False isn't much of a solution.

This puts me firmly in the 'make numeric comparisons give the right
answer' camp.

Thanks,

Mark


More information about the Python-Dev mailing list