On Fri, Mar 19, 2010 at 6:43 PM, Terry Reedy <tjre...@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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
