[Python-Dev] Re: Decimal data type issues (original) (raw)

Bob Ippolito bob at redivi.com
Tue Apr 13 17:13:22 EDT 2004

On Apr 13, 2004, at 4:34 PM, Paul Moore wrote:

"Batista, Facundo" <FBatista at uniFON.com.ar> writes:

[...]

Actually, imposing the limit means more code and complexity, and I don't find any benefit. But as I answered to Paul, I'm searching for community agreement before changing functionality that I found in the implementation [...] So, while Decimal(25) == 25 is True, hash(Decimal(25)) should be equal to hash(25).

The detail is that you can NOT compare Decimal to floats or strings, so maybe we should not worry about them to give the same hashes. I'm OK to make hash(int or long) == hash(Decimal(int or long)). But only to int or long, not float nor string. Do you agree? So far, I've found your instincts to be pretty good. I'd say 1. Remove the limits. 2. Make hashes the same for int/long, but not str/float.

Make hash(Decimal('123.1')) == hash(Decimal('123.1')) .. there is no reason not to. What's the point of having a Decimal type if the only way to get an accurate representation of a non-integer is to do some garbage like Decimal(1231)/Decimal(10)?

hash(float(1.0)) == hash(Decimal(1)) comes for free, because hash(float(1.0)) == hash(1). For the few other non-integer numbers that can be accurately represented as floating point, it might make sense to keep the same property? Though I suppose that is pretty what-the-heck-does-C-do specific, so I wouldn't blame anyone if this property couldn't be maintained.

3. While I'm at it, I'm OK with the names you suggest for the 3 extra functions.

-bob

More information about the Python-Dev mailing list