On Fri, Mar 19, 2010 at 1:17 PM, Case Vanhorsen <cas...@gmail.com> wrote: > On Fri, Mar 19, 2010 at 3:07 AM, Mark Dickinson <dicki...@gmail.com> wrote: >> On Fri, Mar 19, 2010 at 9:37 AM, Mark Dickinson <dicki...@gmail.com> wrote: >>> Making hashes of int, >>> float, Decimal *and* Fraction all compatible with one another, >>> efficient for ints and floats, and not grossly inefficient for >>> Fractions and Decimals, is kinda hairy, though I have a couple of >>> ideas of how it could be done. >> >> To elaborate, here's a cute scheme for the above, which is actually >> remarkably close to what Python already does for ints and floats, and >> which doesn't require any of the numeric types to figure out whether >> it's exactly equal to an instance of some other numeric type.
> Will this change the result of hashing a long? I know that both gmpy > and SAGE use their own hash implementations for performance reasons. I > understand that CPython's hash function is an implementation detail, > but there are external modules that rely on the existing hash > behavior. Yes, it would change the hash of a long. What external modules are there that rely on existing hash behaviour? And exactly what behaviour do they rely on? 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
