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

Steven D'Aprano steve at pearwood.info
Wed Mar 17 12:43:35 CET 2010

```On Wed, 17 Mar 2010 10:01:12 am Guido van Rossum wrote:
> On Tue, Mar 16, 2010 at 2:32 PM, Steven D'Aprano <steve at pearwood.info>
wrote:
> > But mixed arithmetic runs into the problem, what do you want the
> > result type to be? Given (say) decimal+float, returning either a
> > Decimal or a float will be the wrong thing to do some of the time,
> > so better to prohibit mixed arithmetic and let folks handle their
> > own conversions. So +1 on continuing to prohibit mixed arithmetic.
>
> I'm not disagreeing, but I really wonder, what is the value of
> supporting mixed comparisons then? Just because you *can* assign a
> meaning to it doesn't mean you should.

Any mixed comparison with floats is already risky:

>>> 1e20 + 1e4 == 10**20 + 10**4
False

but we allow them anyway because they're too useful and too obvious not
to. The problems with (say) floating point equality are far too well
known to need me give examples, but I will anyway *wink*:

>>> 1.3 == 3.7 - 2.4
False

but we allow it anyway, partly from tradition ("floats have always been
like that") and partly because, frankly, laziness is a virtue. It would
be painful not to be able to say (e.g.):

>>> 1.25 == 3.75 - 2.5
True
>>> 10.0 > 1
True

My defence of mixed comparisons is the same. If I'm doing serious maths
work, then I'm going to be comparing numbers carefully, and not just
tossing a comparison operator between them. But for simple
calculations, or using the interactive interpreter as a calculator, or
if I need to sort a list of mixed numbers without caring whether they
are ints or floats or Decimals, laziness is a virtue. If your needs for
accuracy aren't high, you can go far by comparing floats with ==. Why
shouldn't the same apply to mixed floats and Decimals?

Having said all that, I've just re-read the PEP, and spotted a fly in
the ointment... hash.

If we allow Decimals to compare equal to floats, that presumably implies
that they need to hash equal. That may be simple enough for integer
valued floats, but what non-integer values?

--
Steven D'Aprano
```