[Python-Dev] Mixing float and Decimal -- thread reboot

[Guido van Rossum]

On Mon, Mar 22, 2010 at 8:39 AM, Raymond Hettinger
<raymond.hettinger at gmail.com> wrote:
> My instinct says that we're asking for trouble if comparisons have
> different coercion rules than arithmetic operations.

Sorry, no, this is a station we passed long ago when float-long
comparison was fixed to do the comparison exactly (but other mixed ops
continue to convert the long to a float). Otherwise you'll get a
violation of "if x < y and y < z then it follows that x < z".

(FWIW, my instinct used to be the same as yours, but I got better. :-)

> That would suggest that we follow the chain of lossless conversions:
>
>   Fraction + float --> Fraction

Besides the obvious backwards compatibility problem, I also just
really think that this would be a mistake. Fraction corresponds to
Rational in PEP 3141's numeric tower and float corresponds to Real (as
does Decimal). The convention is to only move to the more general type
in the numeric tower.

Now we all know that floats (being a fixed number of bits) are
actually representable as rationals as well, but *that's not how we
think about them!*

>   Fraction + decimal --> Fraction

This also violates the natural direction in the numeric tower.

>   Decimal + float --> Decimal

If everybody associated with the Decimal implementation wants this I
won't stop you; as I repeatedly said my intuition about this one (as
opposed to the other two above) is very weak.

> That way, arithmetic coercions match comparison coercions.

Which is not a requirement.

> We preserve get Mark's fast, clean new universal hash function.

That hash function (or another that matches the requirements) is a given.

> The equality/hash homomorphism is preserved.

That is also a given (except I don't know if homomorphism is the right
word to use).

> And a decimal context is not needed for any of the coercions
> (it is needed for the addition between two decimals once coercion
> has happened, but that is completely normal for Decimal so there
> are no surprises).

Doesn't strike me as a deciding argument.

-- 
--Guido van Rossum (python.org/~guido)