mirror of
https://github.com/python/cpython.git
synced 2025-10-31 10:26:02 +00:00
9a828d3c61
exactly once. But the test code can't know that, as the number of times __cmp__ is called depends on internal details of the dict implementation. This is especially nasty because the __hash__ method returns the address of the class object, so the hash codes seen by the dict can vary across runs, causing the dict to use a different probe order across runs. I just happened to see this test fail about 1 run in 7 today, but only under a release build and when passing -O to Python. So, changed the test to be predictable across runs.
52 lines
1.7 KiB
Python
52 lines
1.7 KiB
Python
# Python test set -- part 3, built-in operations.
|
|
|
|
|
|
print '3. Operations'
|
|
print 'XXX Mostly not yet implemented'
|
|
|
|
|
|
print '3.1 Dictionary lookups succeed even if __cmp__() raises an exception'
|
|
|
|
# SourceForge bug #112558:
|
|
# http://sourceforge.net/bugs/?func=detailbug&bug_id=112558&group_id=5470
|
|
|
|
class BadDictKey:
|
|
already_printed_raising_error = 0
|
|
|
|
def __hash__(self):
|
|
return hash(self.__class__)
|
|
|
|
def __cmp__(self, other):
|
|
if isinstance(other, self.__class__):
|
|
if not BadDictKey.already_printed_raising_error:
|
|
# How many times __cmp__ gets called depends on the hash
|
|
# code and the internals of the dict implementation; we
|
|
# know it will be called at least once, but that's it.
|
|
# already_printed_raising_error makes sure the expected-
|
|
# output file prints the msg at most once.
|
|
BadDictKey.already_printed_raising_error = 1
|
|
print "raising error"
|
|
raise RuntimeError, "gotcha"
|
|
return other
|
|
|
|
d = {}
|
|
x1 = BadDictKey()
|
|
x2 = BadDictKey()
|
|
d[x1] = 1
|
|
d[x2] = 2
|
|
print "No exception passed through."
|
|
|
|
# Dict resizing bug, found by Jack Jansen in 2.2 CVS development.
|
|
# This version got an assert failure in debug build, infinite loop in
|
|
# release build. Unfortunately, provoking this kind of stuff requires
|
|
# a mix of inserts and deletes hitting exactly the right hash codes in
|
|
# exactly the right order, and I can't think of a randomized approach
|
|
# that would be *likely* to hit a failing case in reasonable time.
|
|
|
|
d = {}
|
|
for i in range(5):
|
|
d[i] = i
|
|
for i in range(5):
|
|
del d[i]
|
|
for i in range(5, 9): # i==8 was the problem
|
|
d[i] = i
|