mirror of
https://github.com/python/cpython.git
synced 2025-11-04 11:49:12 +00:00
486 lines
19 KiB
Python
486 lines
19 KiB
Python
from test import support, seq_tests
|
|
import unittest
|
|
|
|
import gc
|
|
import pickle
|
|
|
|
# For tuple hashes, we normally only run a test to ensure that we get
|
|
# the same results across platforms in a handful of cases. If that's
|
|
# so, there's no real point to running more. Set RUN_ALL_HASH_TESTS to
|
|
# run more anyway. That's usually of real interest only when analyzing,
|
|
# or changing, the hash algorithm. In which case it's usually also
|
|
# most useful to set JUST_SHOW_HASH_RESULTS, to see all the results
|
|
# instead of wrestling with test "failures". See the bottom of the
|
|
# file for extensive notes on what we're testing here and why.
|
|
RUN_ALL_HASH_TESTS = False
|
|
JUST_SHOW_HASH_RESULTS = False # if RUN_ALL_HASH_TESTS, just display
|
|
|
|
class TupleTest(seq_tests.CommonTest):
|
|
type2test = tuple
|
|
|
|
def test_getitem_error(self):
|
|
t = ()
|
|
msg = "tuple indices must be integers or slices"
|
|
with self.assertRaisesRegex(TypeError, msg):
|
|
t['a']
|
|
|
|
def test_constructors(self):
|
|
super().test_constructors()
|
|
# calling built-in types without argument must return empty
|
|
self.assertEqual(tuple(), ())
|
|
t0_3 = (0, 1, 2, 3)
|
|
t0_3_bis = tuple(t0_3)
|
|
self.assertTrue(t0_3 is t0_3_bis)
|
|
self.assertEqual(tuple([]), ())
|
|
self.assertEqual(tuple([0, 1, 2, 3]), (0, 1, 2, 3))
|
|
self.assertEqual(tuple(''), ())
|
|
self.assertEqual(tuple('spam'), ('s', 'p', 'a', 'm'))
|
|
self.assertEqual(tuple(x for x in range(10) if x % 2),
|
|
(1, 3, 5, 7, 9))
|
|
|
|
def test_keyword_args(self):
|
|
with self.assertRaisesRegex(TypeError, 'keyword argument'):
|
|
tuple(sequence=())
|
|
|
|
def test_truth(self):
|
|
super().test_truth()
|
|
self.assertTrue(not ())
|
|
self.assertTrue((42, ))
|
|
|
|
def test_len(self):
|
|
super().test_len()
|
|
self.assertEqual(len(()), 0)
|
|
self.assertEqual(len((0,)), 1)
|
|
self.assertEqual(len((0, 1, 2)), 3)
|
|
|
|
def test_iadd(self):
|
|
super().test_iadd()
|
|
u = (0, 1)
|
|
u2 = u
|
|
u += (2, 3)
|
|
self.assertTrue(u is not u2)
|
|
|
|
def test_imul(self):
|
|
super().test_imul()
|
|
u = (0, 1)
|
|
u2 = u
|
|
u *= 3
|
|
self.assertTrue(u is not u2)
|
|
|
|
def test_tupleresizebug(self):
|
|
# Check that a specific bug in _PyTuple_Resize() is squashed.
|
|
def f():
|
|
for i in range(1000):
|
|
yield i
|
|
self.assertEqual(list(tuple(f())), list(range(1000)))
|
|
|
|
# We expect tuples whose base components have deterministic hashes to
|
|
# have deterministic hashes too - and, indeed, the same hashes across
|
|
# platforms with hash codes of the same bit width.
|
|
def test_hash_exact(self):
|
|
def check_one_exact(t, e32, e64):
|
|
got = hash(t)
|
|
expected = e32 if support.NHASHBITS == 32 else e64
|
|
if got != expected:
|
|
msg = f"FAIL hash({t!r}) == {got} != {expected}"
|
|
self.fail(msg)
|
|
|
|
check_one_exact((), 750394483, 5740354900026072187)
|
|
check_one_exact((0,), 1214856301, -8753497827991233192)
|
|
check_one_exact((0, 0), -168982784, -8458139203682520985)
|
|
check_one_exact((0.5,), 2077348973, -408149959306781352)
|
|
check_one_exact((0.5, (), (-2, 3, (4, 6))), 714642271,
|
|
-1845940830829704396)
|
|
|
|
# Various tests for hashing of tuples to check that we get few collisions.
|
|
# Does something only if RUN_ALL_HASH_TESTS is true.
|
|
#
|
|
# Earlier versions of the tuple hash algorithm had massive collisions
|
|
# reported at:
|
|
# - https://bugs.python.org/issue942952
|
|
# - https://bugs.python.org/issue34751
|
|
def test_hash_optional(self):
|
|
from itertools import product
|
|
|
|
if not RUN_ALL_HASH_TESTS:
|
|
return
|
|
|
|
# If specified, `expected` is a 2-tuple of expected
|
|
# (number_of_collisions, pileup) values, and the test fails if
|
|
# those aren't the values we get. Also if specified, the test
|
|
# fails if z > `zlimit`.
|
|
def tryone_inner(tag, nbins, hashes, expected=None, zlimit=None):
|
|
from collections import Counter
|
|
|
|
nballs = len(hashes)
|
|
mean, sdev = support.collision_stats(nbins, nballs)
|
|
c = Counter(hashes)
|
|
collisions = nballs - len(c)
|
|
z = (collisions - mean) / sdev
|
|
pileup = max(c.values()) - 1
|
|
del c
|
|
got = (collisions, pileup)
|
|
failed = False
|
|
prefix = ""
|
|
if zlimit is not None and z > zlimit:
|
|
failed = True
|
|
prefix = f"FAIL z > {zlimit}; "
|
|
if expected is not None and got != expected:
|
|
failed = True
|
|
prefix += f"FAIL {got} != {expected}; "
|
|
if failed or JUST_SHOW_HASH_RESULTS:
|
|
msg = f"{prefix}{tag}; pileup {pileup:,} mean {mean:.1f} "
|
|
msg += f"coll {collisions:,} z {z:+.1f}"
|
|
if JUST_SHOW_HASH_RESULTS:
|
|
import sys
|
|
print(msg, file=sys.__stdout__)
|
|
else:
|
|
self.fail(msg)
|
|
|
|
def tryone(tag, xs,
|
|
native32=None, native64=None, hi32=None, lo32=None,
|
|
zlimit=None):
|
|
NHASHBITS = support.NHASHBITS
|
|
hashes = list(map(hash, xs))
|
|
tryone_inner(tag + f"; {NHASHBITS}-bit hash codes",
|
|
1 << NHASHBITS,
|
|
hashes,
|
|
native32 if NHASHBITS == 32 else native64,
|
|
zlimit)
|
|
|
|
if NHASHBITS > 32:
|
|
shift = NHASHBITS - 32
|
|
tryone_inner(tag + "; 32-bit upper hash codes",
|
|
1 << 32,
|
|
[h >> shift for h in hashes],
|
|
hi32,
|
|
zlimit)
|
|
|
|
mask = (1 << 32) - 1
|
|
tryone_inner(tag + "; 32-bit lower hash codes",
|
|
1 << 32,
|
|
[h & mask for h in hashes],
|
|
lo32,
|
|
zlimit)
|
|
|
|
# Tuples of smallish positive integers are common - nice if we
|
|
# get "better than random" for these.
|
|
tryone("range(100) by 3", list(product(range(100), repeat=3)),
|
|
(0, 0), (0, 0), (4, 1), (0, 0))
|
|
|
|
# A previous hash had systematic problems when mixing integers of
|
|
# similar magnitude but opposite sign, obscurely related to that
|
|
# j ^ -2 == -j when j is odd.
|
|
cands = list(range(-10, -1)) + list(range(9))
|
|
|
|
# Note: -1 is omitted because hash(-1) == hash(-2) == -2, and
|
|
# there's nothing the tuple hash can do to avoid collisions
|
|
# inherited from collisions in the tuple components' hashes.
|
|
tryone("-10 .. 8 by 4", list(product(cands, repeat=4)),
|
|
(0, 0), (0, 0), (0, 0), (0, 0))
|
|
del cands
|
|
|
|
# The hashes here are a weird mix of values where all the
|
|
# variation is in the lowest bits and across a single high-order
|
|
# bit - the middle bits are all zeroes. A decent hash has to
|
|
# both propagate low bits to the left and high bits to the
|
|
# right. This is also complicated a bit in that there are
|
|
# collisions among the hashes of the integers in L alone.
|
|
L = [n << 60 for n in range(100)]
|
|
tryone("0..99 << 60 by 3", list(product(L, repeat=3)),
|
|
(0, 0), (0, 0), (0, 0), (324, 1))
|
|
del L
|
|
|
|
# Used to suffer a massive number of collisions.
|
|
tryone("[-3, 3] by 18", list(product([-3, 3], repeat=18)),
|
|
(7, 1), (0, 0), (7, 1), (6, 1))
|
|
|
|
# And even worse. hash(0.5) has only a single bit set, at the
|
|
# high end. A decent hash needs to propagate high bits right.
|
|
tryone("[0, 0.5] by 18", list(product([0, 0.5], repeat=18)),
|
|
(5, 1), (0, 0), (9, 1), (12, 1))
|
|
|
|
# Hashes of ints and floats are the same across platforms.
|
|
# String hashes vary even on a single platform across runs, due
|
|
# to hash randomization for strings. So we can't say exactly
|
|
# what this should do. Instead we insist that the # of
|
|
# collisions is no more than 4 sdevs above the theoretically
|
|
# random mean. Even if the tuple hash can't achieve that on its
|
|
# own, the string hash is trying to be decently pseudo-random
|
|
# (in all bit positions) on _its_ own. We can at least test
|
|
# that the tuple hash doesn't systematically ruin that.
|
|
tryone("4-char tuples",
|
|
list(product("abcdefghijklmnopqrstuvwxyz", repeat=4)),
|
|
zlimit=4.0)
|
|
|
|
# The "old tuple test". See https://bugs.python.org/issue942952.
|
|
# Ensures, for example, that the hash:
|
|
# is non-commutative
|
|
# spreads closely spaced values
|
|
# doesn't exhibit cancellation in tuples like (x,(x,y))
|
|
N = 50
|
|
base = list(range(N))
|
|
xp = list(product(base, repeat=2))
|
|
inps = base + list(product(base, xp)) + \
|
|
list(product(xp, base)) + xp + list(zip(base))
|
|
tryone("old tuple test", inps,
|
|
(2, 1), (0, 0), (52, 49), (7, 1))
|
|
del base, xp, inps
|
|
|
|
# The "new tuple test". See https://bugs.python.org/issue34751.
|
|
# Even more tortured nesting, and a mix of signed ints of very
|
|
# small magnitude.
|
|
n = 5
|
|
A = [x for x in range(-n, n+1) if x != -1]
|
|
B = A + [(a,) for a in A]
|
|
L2 = list(product(A, repeat=2))
|
|
L3 = L2 + list(product(A, repeat=3))
|
|
L4 = L3 + list(product(A, repeat=4))
|
|
# T = list of testcases. These consist of all (possibly nested
|
|
# at most 2 levels deep) tuples containing at most 4 items from
|
|
# the set A.
|
|
T = A
|
|
T += [(a,) for a in B + L4]
|
|
T += product(L3, B)
|
|
T += product(L2, repeat=2)
|
|
T += product(B, L3)
|
|
T += product(B, B, L2)
|
|
T += product(B, L2, B)
|
|
T += product(L2, B, B)
|
|
T += product(B, repeat=4)
|
|
assert len(T) == 345130
|
|
tryone("new tuple test", T,
|
|
(9, 1), (0, 0), (21, 5), (6, 1))
|
|
|
|
def test_repr(self):
|
|
l0 = tuple()
|
|
l2 = (0, 1, 2)
|
|
a0 = self.type2test(l0)
|
|
a2 = self.type2test(l2)
|
|
|
|
self.assertEqual(str(a0), repr(l0))
|
|
self.assertEqual(str(a2), repr(l2))
|
|
self.assertEqual(repr(a0), "()")
|
|
self.assertEqual(repr(a2), "(0, 1, 2)")
|
|
|
|
def _not_tracked(self, t):
|
|
# Nested tuples can take several collections to untrack
|
|
gc.collect()
|
|
gc.collect()
|
|
self.assertFalse(gc.is_tracked(t), t)
|
|
|
|
def _tracked(self, t):
|
|
self.assertTrue(gc.is_tracked(t), t)
|
|
gc.collect()
|
|
gc.collect()
|
|
self.assertTrue(gc.is_tracked(t), t)
|
|
|
|
@support.cpython_only
|
|
def test_track_literals(self):
|
|
# Test GC-optimization of tuple literals
|
|
x, y, z = 1.5, "a", []
|
|
|
|
self._not_tracked(())
|
|
self._not_tracked((1,))
|
|
self._not_tracked((1, 2))
|
|
self._not_tracked((1, 2, "a"))
|
|
self._not_tracked((1, 2, (None, True, False, ()), int))
|
|
self._not_tracked((object(),))
|
|
self._not_tracked(((1, x), y, (2, 3)))
|
|
|
|
# Tuples with mutable elements are always tracked, even if those
|
|
# elements are not tracked right now.
|
|
self._tracked(([],))
|
|
self._tracked(([1],))
|
|
self._tracked(({},))
|
|
self._tracked((set(),))
|
|
self._tracked((x, y, z))
|
|
|
|
def check_track_dynamic(self, tp, always_track):
|
|
x, y, z = 1.5, "a", []
|
|
|
|
check = self._tracked if always_track else self._not_tracked
|
|
check(tp())
|
|
check(tp([]))
|
|
check(tp(set()))
|
|
check(tp([1, x, y]))
|
|
check(tp(obj for obj in [1, x, y]))
|
|
check(tp(set([1, x, y])))
|
|
check(tp(tuple([obj]) for obj in [1, x, y]))
|
|
check(tuple(tp([obj]) for obj in [1, x, y]))
|
|
|
|
self._tracked(tp([z]))
|
|
self._tracked(tp([[x, y]]))
|
|
self._tracked(tp([{x: y}]))
|
|
self._tracked(tp(obj for obj in [x, y, z]))
|
|
self._tracked(tp(tuple([obj]) for obj in [x, y, z]))
|
|
self._tracked(tuple(tp([obj]) for obj in [x, y, z]))
|
|
|
|
@support.cpython_only
|
|
def test_track_dynamic(self):
|
|
# Test GC-optimization of dynamically constructed tuples.
|
|
self.check_track_dynamic(tuple, False)
|
|
|
|
@support.cpython_only
|
|
def test_track_subtypes(self):
|
|
# Tuple subtypes must always be tracked
|
|
class MyTuple(tuple):
|
|
pass
|
|
self.check_track_dynamic(MyTuple, True)
|
|
|
|
@support.cpython_only
|
|
def test_bug7466(self):
|
|
# Trying to untrack an unfinished tuple could crash Python
|
|
self._not_tracked(tuple(gc.collect() for i in range(101)))
|
|
|
|
def test_repr_large(self):
|
|
# Check the repr of large list objects
|
|
def check(n):
|
|
l = (0,) * n
|
|
s = repr(l)
|
|
self.assertEqual(s,
|
|
'(' + ', '.join(['0'] * n) + ')')
|
|
check(10) # check our checking code
|
|
check(1000000)
|
|
|
|
def test_iterator_pickle(self):
|
|
# Userlist iterators don't support pickling yet since
|
|
# they are based on generators.
|
|
data = self.type2test([4, 5, 6, 7])
|
|
for proto in range(pickle.HIGHEST_PROTOCOL + 1):
|
|
itorg = iter(data)
|
|
d = pickle.dumps(itorg, proto)
|
|
it = pickle.loads(d)
|
|
self.assertEqual(type(itorg), type(it))
|
|
self.assertEqual(self.type2test(it), self.type2test(data))
|
|
|
|
it = pickle.loads(d)
|
|
next(it)
|
|
d = pickle.dumps(it, proto)
|
|
self.assertEqual(self.type2test(it), self.type2test(data)[1:])
|
|
|
|
def test_reversed_pickle(self):
|
|
data = self.type2test([4, 5, 6, 7])
|
|
for proto in range(pickle.HIGHEST_PROTOCOL + 1):
|
|
itorg = reversed(data)
|
|
d = pickle.dumps(itorg, proto)
|
|
it = pickle.loads(d)
|
|
self.assertEqual(type(itorg), type(it))
|
|
self.assertEqual(self.type2test(it), self.type2test(reversed(data)))
|
|
|
|
it = pickle.loads(d)
|
|
next(it)
|
|
d = pickle.dumps(it, proto)
|
|
self.assertEqual(self.type2test(it), self.type2test(reversed(data))[1:])
|
|
|
|
def test_no_comdat_folding(self):
|
|
# Issue 8847: In the PGO build, the MSVC linker's COMDAT folding
|
|
# optimization causes failures in code that relies on distinct
|
|
# function addresses.
|
|
class T(tuple): pass
|
|
with self.assertRaises(TypeError):
|
|
[3,] + T((1,2))
|
|
|
|
def test_lexicographic_ordering(self):
|
|
# Issue 21100
|
|
a = self.type2test([1, 2])
|
|
b = self.type2test([1, 2, 0])
|
|
c = self.type2test([1, 3])
|
|
self.assertLess(a, b)
|
|
self.assertLess(b, c)
|
|
|
|
# Notes on testing hash codes. The primary thing is that Python doesn't
|
|
# care about "random" hash codes. To the contrary, we like them to be
|
|
# very regular when possible, so that the low-order bits are as evenly
|
|
# distributed as possible. For integers this is easy: hash(i) == i for
|
|
# all not-huge i except i==-1.
|
|
#
|
|
# For tuples of mixed type there's really no hope of that, so we want
|
|
# "randomish" here instead. But getting close to pseudo-random in all
|
|
# bit positions is more expensive than we've been willing to pay for.
|
|
#
|
|
# We can tolerate large deviations from random - what we don't want is
|
|
# catastrophic pileups on a relative handful of hash codes. The dict
|
|
# and set lookup routines remain effective provided that full-width hash
|
|
# codes for not-equal objects are distinct.
|
|
#
|
|
# So we compute various statistics here based on what a "truly random"
|
|
# hash would do, but don't automate "pass or fail" based on those
|
|
# results. Instead those are viewed as inputs to human judgment, and the
|
|
# automated tests merely ensure we get the _same_ results across
|
|
# platforms. In fact, we normally don't bother to run them at all -
|
|
# set RUN_ALL_HASH_TESTS to force it.
|
|
#
|
|
# When global JUST_SHOW_HASH_RESULTS is True, the tuple hash statistics
|
|
# are just displayed to stdout. A typical output line looks like:
|
|
#
|
|
# old tuple test; 32-bit upper hash codes; \
|
|
# pileup 49 mean 7.4 coll 52 z +16.4
|
|
#
|
|
# "old tuple test" is just a string name for the test being run.
|
|
#
|
|
# "32-bit upper hash codes" means this was run under a 64-bit build and
|
|
# we've shifted away the lower 32 bits of the hash codes.
|
|
#
|
|
# "pileup" is 0 if there were no collisions across those hash codes.
|
|
# It's 1 less than the maximum number of times any single hash code was
|
|
# seen. So in this case, there was (at least) one hash code that was
|
|
# seen 50 times: that hash code "piled up" 49 more times than ideal.
|
|
#
|
|
# "mean" is the number of collisions a perfectly random hash function
|
|
# would have yielded, on average.
|
|
#
|
|
# "coll" is the number of collisions actually seen.
|
|
#
|
|
# "z" is "coll - mean" divided by the standard deviation of the number
|
|
# of collisions a perfectly random hash function would suffer. A
|
|
# positive value is "worse than random", and negative value "better than
|
|
# random". Anything of magnitude greater than 3 would be highly suspect
|
|
# for a hash function that claimed to be random. It's essentially
|
|
# impossible that a truly random function would deliver a result 16.4
|
|
# sdevs "worse than random".
|
|
#
|
|
# But we don't care here! That's why the test isn't coded to fail.
|
|
# Knowing something about how the high-order hash code bits behave
|
|
# provides insight, but is irrelevant to how the dict and set lookup
|
|
# code performs. The low-order bits are much more important to that,
|
|
# and on the same test those did "just like random":
|
|
#
|
|
# old tuple test; 32-bit lower hash codes; \
|
|
# pileup 1 mean 7.4 coll 7 z -0.2
|
|
#
|
|
# So there are always tradeoffs to consider. For another:
|
|
#
|
|
# 0..99 << 60 by 3; 32-bit hash codes; \
|
|
# pileup 0 mean 116.4 coll 0 z -10.8
|
|
#
|
|
# That was run under a 32-bit build, and is spectacularly "better than
|
|
# random". On a 64-bit build the wider hash codes are fine too:
|
|
#
|
|
# 0..99 << 60 by 3; 64-bit hash codes; \
|
|
# pileup 0 mean 0.0 coll 0 z -0.0
|
|
#
|
|
# but their lower 32 bits are poor:
|
|
#
|
|
# 0..99 << 60 by 3; 32-bit lower hash codes; \
|
|
# pileup 1 mean 116.4 coll 324 z +19.2
|
|
#
|
|
# In a statistical sense that's waaaaay too many collisions, but (a) 324
|
|
# collisions out of a million hash codes isn't anywhere near being a
|
|
# real problem; and, (b) the worst pileup on a single hash code is a measly
|
|
# 1 extra. It's a relatively poor case for the tuple hash, but still
|
|
# fine for practical use.
|
|
#
|
|
# This isn't, which is what Python 3.7.1 produced for the hashes of
|
|
# itertools.product([0, 0.5], repeat=18). Even with a fat 64-bit
|
|
# hashcode, the highest pileup was over 16,000 - making a dict/set
|
|
# lookup on one of the colliding values thousands of times slower (on
|
|
# average) than we expect.
|
|
#
|
|
# [0, 0.5] by 18; 64-bit hash codes; \
|
|
# pileup 16,383 mean 0.0 coll 262,128 z +6073641856.9
|
|
# [0, 0.5] by 18; 32-bit lower hash codes; \
|
|
# pileup 262,143 mean 8.0 coll 262,143 z +92683.6
|
|
|
|
if __name__ == "__main__":
|
|
unittest.main()
|