[Python-Dev] Decimal <-> float comparisons in py3k.

[Raymond Hettinger]

On Mar 18, 2010, at 5:23 AM, Steven D'Aprano wrote:

> On Thu, 18 Mar 2010 08:58:25 am Raymond Hettinger wrote:
>> On Mar 17, 2010, at 1:59 PM, Steven D'Aprano wrote:
>>> On Thu, 18 Mar 2010 07:44:21 am Raymond Hettinger wrote:
>>>> The spectrum of options from worst to best is
>>>> 1) compare but give the wrong answer
>>>> 2) compare but give the right answer
>>>> 3) refuse to compare.
>>> 
>>> Why is 3 the best? If there is a right answer to give, surely
>>> giving the right answer it is better than not?
>> 
>> From the early days of the decimal module,
>> we've thought that mixed float-decimal operations
>> are 1) a bit perilous and 2) have few, if any good
>> use cases.
> 
> When it comes to *arithmetic* operations, I agree. Is there anyone on 
> python-dev willing to argue the case for allowing implicit mixed 
> float/Decimal arithmetic operations? The arguments in the PEP seem 
> pretty convincing to me, and I'm not suggesting we change that.
> 
> But comparison operations are different. For starters, you don't need to 
> worry about whether to return a float or a Decimal, because you always 
> get a bool. In theory, both Decimals and floats are representations of 
> the same underlying thing, namely real numbers, and it seems strange to 
> me that I can't ask whether two such real numbers are equal just 
> because their storage implementation is different.
> 
> I can see three reasonable reasons for avoiding mixed comparisons:
> 
> (1) To avoid confusing float-naive users (but they're confused by pure 
> float comparisons too).
> 
> (2) To avoid mixed arithmetic operations (but comparisons aren't 
> arithmetic).
> 
> (3) If Decimals and floats compare equal, they must hash equal, and 
> currently they don't (but Mark Dickinson thinks he has a solution for 
> that).

Thanks for the thoughtful post.

The question is which behavior is most useful, most of the time.
If a person truly wants to do mixed comparisons, it's trivially
easy to do so in a way that is explicit:

   somedecimal < Decimal.from_float(somefloat)

My thought is that intentional mixed compares of float and decimal 
are very rare relative to unintentional cases.  IOW, most of the
time that x<y makes a float/decimal comparison, it is actually an error
(or the user simply doesn't understand what his or her code is
actually doing).  That user is best served by refusing the temptation
to guess that they really wanted to go down this path.

The zen of this particular problem:

    explicit is already easy
    implicit is likely to let errors pass silently
    therefore, explicit is better than implicit

   the special and rare case of really wanting a float/decimal comparison
   is rare enough that it isn't worth making the 
   operation implicit, especially when the explicit option is so easy.

Do you want protection from probable errors or do you have
compelling use cases for implicit conversion behavior
where an explicit conversion would have been too much of 
a burden?


Raymond