RetroSearch Browse

Sat Mar 20 12:06:30 CET 2010 · https://mail.python.org/pipermail/python-dev/2010-March/098603.html

On Fri, Mar 19, 2010 at 1:17 PM, Case Vanhorsen <casevh at gmail.com> wrote:
> On Fri, Mar 19, 2010 at 3:07 AM, Mark Dickinson <dickinsm at gmail.com> wrote:
>> On Fri, Mar 19, 2010 at 9:37 AM, Mark Dickinson <dickinsm at 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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2010-March/098603.html below:

[Python-Dev] Decimal <-> float comparisons in py3k.