From 537ad7ad9fdefa44fdfd7f5cbee198ad381deb60 Mon Sep 17 00:00:00 2001 From: R David Murray Date: Sun, 10 Jul 2016 12:33:18 -0400 Subject: #20647: Update dictobject.c comments to account for randomized string hashes. Patch by Jaysinh Shukla. --- Objects/dictobject.c | 13 +++++-------- 1 file changed, 5 insertions(+), 8 deletions(-) diff --git a/Objects/dictobject.c b/Objects/dictobject.c index d774586..e04ab2b 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 -- cgit v0.12