On Fri, Mar 19, 2010 at 6:43 PM, Terry Reedy <tjreedy@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