Get rid of the superstitious "~" in dict hashing's "i = (~hash) & mask".
The comment following used to say:
/* We use ~hash instead of hash, as degenerate hash functions, such
as for ints <sigh>, can have lots of leading zeros. It's not
really a performance risk, but better safe than sorry.
12-Dec-00 tim: so ~hash produces lots of leading ones instead --
what's the gain? */
That is, there was never a good reason for doing it. And to the contrary,
as explained on Python-Dev last December, it tended to make the *sum*
(i + incr) & mask (which is the first table index examined in case of
collison) the same "too often" across distinct hashes.
Changing to the simpler "i = hash & mask" reduced the number of string-dict
collisions (== # number of times we go around the lookup for-loop) from about
6 million to 5 million during a full run of the test suite (these are
approximate because the test suite does some random stuff from run to run).
The number of collisions in non-string dicts also decreased, but not as
dramatically.
Note that this may, for a given dict, change the order (wrt previous
releases) of entries exposed by .keys(), .values() and .items(). A number
of std tests suffered bogus failures as a result. For dicts keyed by
small ints, or (less so) by characters, the order is much more likely to be
in increasing order of key now; e.g.,
>>> d = {}
>>> for i in range(10):
... d[i] = i
...
>>> d
{0: 0, 1: 1, 2: 2, 3: 3, 4: 4, 5: 5, 6: 6, 7: 7, 8: 8, 9: 9}
>>>
Unfortunately. people may latch on to that in small examples and draw a
bogus conclusion.
test_support.py
Moved test_extcall's sortdict() into test_support, made it stronger,
and imported sortdict into other std tests that needed it.
test_unicode.py
Excluced cp875 from the "roundtrip over range(128)" test, because
cp875 doesn't have a well-defined inverse for unicode("?", "cp875").
See Python-Dev for excruciating details.
Cookie.py
Chaged various output functions to sort dicts before building
strings from them.
test_extcall
Fiddled the expected-result file. This remains sensitive to native
dict ordering, because, e.g., if there are multiple errors in a
keyword-arg dict (and test_extcall sets up many cases like that), the
specific error Python complains about first depends on native dict
ordering.
diff --git a/Lib/Cookie.py b/Lib/Cookie.py
index b7ee19c..dd116b7 100644
--- a/Lib/Cookie.py
+++ b/Lib/Cookie.py
@@ -70,8 +70,8 @@
>>> C["fig"] = "newton"
>>> C["sugar"] = "wafer"
>>> print C
- Set-Cookie: sugar=wafer;
Set-Cookie: fig=newton;
+ Set-Cookie: sugar=wafer;
Notice that the printable representation of a Cookie is the
appropriate format for a Set-Cookie: header. This is the
@@ -93,8 +93,8 @@
>>> C = Cookie.SmartCookie()
>>> C.load("chips=ahoy; vienna=finger")
>>> print C
- Set-Cookie: vienna=finger;
Set-Cookie: chips=ahoy;
+ Set-Cookie: vienna=finger;
The load() method is darn-tootin smart about identifying cookies
within a string. Escaped quotation marks, nested semicolons, and other
@@ -493,7 +493,9 @@
# Now add any defined attributes
if attrs is None:
attrs = self._reserved_keys
- for K,V in self.items():
+ items = self.items()
+ items.sort()
+ for K,V in items:
if V == "": continue
if K not in attrs: continue
if K == "expires" and type(V) == type(1):
@@ -586,7 +588,9 @@
def output(self, attrs=None, header="Set-Cookie:", sep="\n"):
"""Return a string suitable for HTTP."""
result = []
- for K,V in self.items():
+ items = self.items()
+ items.sort()
+ for K,V in items:
result.append( V.output(attrs, header) )
return string.join(result, sep)
# end output
@@ -595,14 +599,18 @@
def __repr__(self):
L = []
- for K,V in self.items():
+ items = self.items()
+ items.sort()
+ for K,V in items:
L.append( '%s=%s' % (K,repr(V.value) ) )
return '<%s: %s>' % (self.__class__.__name__, string.join(L))
def js_output(self, attrs=None):
"""Return a string suitable for JavaScript."""
result = []
- for K,V in self.items():
+ items = self.items()
+ items.sort()
+ for K,V in items:
result.append( V.js_output(attrs) )
return string.join(result, "")
# end js_output