On Wed, Mar 17, 2010 at 11:43 AM, Steven D'Aprano <st...@pearwood.info> wrote: > 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?
That is indeed an issue. It can be taken care by checking whether the Decimal instance is exactly representable as a float, and returning the hash of the corresponding float if so. From the patch (http://bugs.python.org/file16544/issue2531.patch): + self_as_float = float(self) + if Decimal.from_float(self_as_float) == self: + return hash(self_as_float) Strictly speaking this only works if the Decimal -> float conversion (which relies on the platform strtod) is accurate to within <1ulp, but that's going to be true in 2.7/3.x on all platforms using David Gay's str<->float conversion code, and is *probably* true for the system strtod on any sane platform, so I don't think it's a real issue. This also slows down the (already slow) hash computation for Decimal a touch. Until people start complaining, or show evidence of applications that require making large dictionaries of Decimal instances, I'm not going to worry about that either. It would be easy to cache the hash value of a Decimal instance if it became necessary. A less messy (but more intrusive) alternative would be to come up with a single sane hash function defined for all rational numbers (plus infinities and nans), and use this function for int, long, float, Decimal and Fraction types. I have a candidate function in mind... Mark _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com