Reimplement PySequence_Contains() and instance_contains(), so they work
safely together and don't duplicate logic (the common logic was factored
out into new private API function _PySequence_IterContains()).
Visible change:
some_complex_number in some_instance
no longer blows up if some_instance has __getitem__ but neither
__contains__ nor __iter__. test_iter changed to ensure that remains true.
diff --git a/Lib/test/test_iter.py b/Lib/test/test_iter.py
index 7d15e1c..22a7c44 100644
--- a/Lib/test/test_iter.py
+++ b/Lib/test/test_iter.py
@@ -474,24 +474,12 @@
# Test iterators with 'x in y' and 'x not in y'.
def test_in_and_not_in(self):
- sc5 = IteratingSequenceClass(5)
- for i in range(5):
- self.assert_(i in sc5)
- # CAUTION: This test fails on 3-12j if sc5 is SequenceClass(5)
- # instead, with:
- # TypeError: cannot compare complex numbers using <, <=, >, >=
- # The trail leads back to instance_contains() in classobject.c,
- # under comment:
- # /* fall back to previous behavior */
- # IteratingSequenceClass(5) avoids the same problem only because
- # it lacks __getitem__: instance_contains *tries* to do a wrong
- # thing with it too, but aborts with an AttributeError the first
- # time it calls instance_item(); PySequence_Contains() then catches
- # that and clears it, and tries the iterator-based "contains"
- # instead. But this is hanging together by a thread.
- for i in "abc", -1, 5, 42.42, (3, 4), [], {1: 1}, 3-12j, sc5:
- self.assert_(i not in sc5)
- del sc5
+ for sc5 in IteratingSequenceClass(5), SequenceClass(5):
+ for i in range(5):
+ self.assert_(i in sc5)
+ for i in "abc", -1, 5, 42.42, (3, 4), [], {1: 1}, 3-12j, sc5:
+ self.assert_(i not in sc5)
+ del sc5
self.assertRaises(TypeError, lambda: 3 in 12)
self.assertRaises(TypeError, lambda: 3 not in map)