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 tim.peters
Recipients belopolsky, benjamin.peterson, christian.heimes, dmalcolm, epicfaace, lemburg, mark.dickinson, rhettinger, serhiy.storchaka, tim.peters
Date 2019-08-16.14:20:10
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
I'm with Mark:  leave numeric hashes alone.  There's no reason to change them, and in addition to what Mark wrote it's a positively Good Thing that `hash(i) == i` for all sufficiently small ints.  Not only is that efficient to compute, it guarantees there are no collisions _at all_ in the common case of a dict indexed by a contiguous range of integers.

The _purpose_ of `hash()` in Python isn't to create an illusion of randomness, it's to support efficient dicts and sets.  Mucking with string hashes was a pragmatic hack to alleviate concerns about DOS attacks specific to string-indexed dicts.  A better technical solution to that would have been to introduce a different flavor of dict with guaranteed good worst-case behaviors, but, pragmatically, a great many users would never realize that's what they really wanted, and it wouldn't have helped pre-existing code at all.

But there's no reason to spread that hack beyond the use cases that needed it, and much reason not to.
Date User Action Args
2019-08-16 14:20:11tim.peterssetrecipients: + tim.peters, lemburg, rhettinger, mark.dickinson, belopolsky, christian.heimes, benjamin.peterson, dmalcolm, serhiy.storchaka, epicfaace
2019-08-16 14:20:11tim.peterssetmessageid: <>
2019-08-16 14:20:11tim.peterslinkissue29535 messages
2019-08-16 14:20:10tim.peterscreate