Message 98215 - Python tracker (original) (raw)

So here's the plan for trunk. The big question is: what should be done for py3k?

For trunk:

• all comparisons (==, !=, <=, >=, <, >) between floats and Decimals return the correct numerical result, as though the float were converted to a Decimal with no loss of precision. Like-signed float and Decimal infinities compare equal. float and Decimal nans compare unequal to everything else, as always.

• check whether anything special needs to be done to make sure that cmp also returns sensible results.

• fix Decimal.hash so that when x == y for a float x and Decimal instance y, hash(x) == hash(y)

• the hash fix above is going to slow down hash computations, so consider caching hash values for Decimal instances (as a _hash attribute on the Decimal object itself). My gut feeling is that this probably isn't worth it, given that Decimal objects probably don't get hashed very often in normal use, but I'll do some timings to find out what the performance impact of the new hash is.

For py3k, the obvious options are:

(A) adopt the above changes, or

(B) keep Decimal and float non-comparable (as currently). In this case, a Decimal-to-float comparison in trunk should probably raise a DeprecationWarning. (Note that DeprecationWarnings are now silent by default, so such a warning wouldn't impact end-users much.)