| 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() |