This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author mark.dickinson
Recipients Arfrever, Giovanni.Bajo, PaulMcMillan, Vlado.Boza, alex, arigo, benjamin.peterson, camara, christian.heimes, dmalcolm, koniiiik, lemburg, mark.dickinson, serhiy.storchaka, vstinner
Date 2012-11-07.11:55:10
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1352289311.38.0.410284809127.issue14621@psf.upfronthosting.co.za>
In-reply-to
Content
[MAL]
> I don't understand why we are only trying to fix the string problem
> and completely ignore other key types.

[Armin]
> estimating the risks of giving up on a valid query for a truly random
> hash, at an overestimated one billion queries per second ...

That's fine in principle, but if this gets extended to integers, note that our current integer hash is about as far from 'truly random' as you can get:

    Python 3.4.0a0 (default:f02555353544, Nov  4 2012, 11:50:12) 
    [GCC 4.2.1 (Apple Inc. build 5664)] on darwin
    Type "help", "copyright", "credits" or "license" for more information.
    >>> [hash(i) for i in range(20)]
    [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19]

Moreover, it's going to be *very* hard to change the int hash while preserving the `x == y implies hash(x) == hash(y)` invariant across all the numeric types (int, float, complex, Decimal, Fraction, 3rd-party types that need to remain compatible).
History
Date User Action Args
2012-11-07 11:55:11mark.dickinsonsetrecipients: + mark.dickinson, lemburg, arigo, vstinner, christian.heimes, benjamin.peterson, Arfrever, alex, dmalcolm, Giovanni.Bajo, PaulMcMillan, serhiy.storchaka, Vlado.Boza, koniiiik, camara
2012-11-07 11:55:11mark.dickinsonsetmessageid: <1352289311.38.0.410284809127.issue14621@psf.upfronthosting.co.za>
2012-11-07 11:55:11mark.dickinsonlinkissue14621 messages
2012-11-07 11:55:10mark.dickinsoncreate