[Python-checkins] cpython (merge 3.5 -> default): Merge: #20647: Update dictobject.c comments to account for randomized string

[r.david.murray]

https://hg.python.org/cpython/rev/31cdf23da19d
changeset:   102299:31cdf23da19d
parent:      102297:41dfd92f48f0
parent:      102298:74109d87283f
user:        R David Murray <rdmurray at bitdance.com>
date:        Sun Jul 10 12:40:03 2016 -0400
summary:
  Merge: #20647: Update dictobject.c comments to account for randomized string hashes.

files:
  Objects/dictobject.c |  13 +++++--------
  1 files changed, 5 insertions(+), 8 deletions(-)


diff --git a/Objects/dictobject.c b/Objects/dictobject.c
--- a/Objects/dictobject.c
+++ b/Objects/dictobject.c
@@ -88,20 +88,17 @@
 /*
 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

-- 
Repository URL: https://hg.python.org/cpython