From: R David Murray Date: Sun, 10 Jul 2016 16:33:18 +0000 (-0400) Subject: #20647: Update dictobject.c comments to account for randomized string hashes. X-Git-Tag: v3.6.0a3~13^2 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=537ad7ad9fdefa44fdfd7f5cbee198ad381deb60;p=thirdparty%2FPython%2Fcpython.git #20647: Update dictobject.c comments to account for randomized string hashes. Patch by Jaysinh Shukla. --- diff --git a/Objects/dictobject.c b/Objects/dictobject.c index d7745860e47a..e04ab2b92f44 100644 --- a/Objects/dictobject.c +++ b/Objects/dictobject.c @@ -88,20 +88,17 @@ it's USABLE_FRACTION (currently two-thirds) full. /* Major subtleties ahead: Most hash schemes depend on having a "good" hash function, in the sense of simulating randomness. Python doesn't: its most -important hash functions (for strings and ints) are very regular in common +important hash functions (for ints) are very regular in common cases: - >>> map(hash, (0, 1, 2, 3)) + >>>[hash(i) for i in range(4)] [0, 1, 2, 3] - >>> map(hash, ("namea", "nameb", "namec", "named")) - [-1658398457, -1658398460, -1658398459, -1658398462] - >>> This isn't necessarily bad! To the contrary, in a table of size 2**i, taking the low-order i bits as the initial table index is extremely fast, and there -are no collisions at all for dicts indexed by a contiguous range of ints. -The same is approximately true when keys are "consecutive" strings. So this -gives better-than-random behavior in common cases, and that's very desirable. +are no collisions at all for dicts indexed by a contiguous range of ints. So +this gives better-than-random behavior in common cases, and that's very +desirable. OTOH, when collisions occur, the tendency to fill contiguous slices of the hash table makes a good collision resolution strategy crucial. Taking only