[Python-Dev] Re: Decimal data type issues

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.


More information about the Python-Dev mailing list