Upon insertion, if memory runs out, the deque was left in a corrupted state.

deque_item(): a performance bug: the linked list of blocks was followed
from the left in most cases, because the test (i < (deque->len >> 1)) was
after "i %= BLOCKLEN".

deque_clear(): replaced a call to deque_len() with deque->len; not sure what
this call was here for, nor if all compilers under the sun would inline it.

deque_traverse(): I belive that it could be called by the GC when the deque
has leftblock==rightblock==NULL, because it is tracked before the first block
is allocated (though closely before).  Still, a C extension module subclassing
deque could provide its own tp_alloc that could trigger a GC collection after
the PyObject_GC_Track()...

deque_richcompare(): rewrote to cleanly check for end-of-iterations instead of
relying on deque.__iter__().next() to succeed exactly len(deque) times -- an
assumption which can break if deques are subclassed.  Added a test.

I wonder if the length should be explicitely bounded to INT_MAX, with
OverflowErrors, as in listobject.c.  On 64-bit machines, adding more than
INT_MAX in the deque will result in trouble.  (Note to anyone/me fixing
this: carefully check for overflows if len is close to INT_MAX in the
following functions: deque_rotate(), deque_item(), deque_ass_item())

Lib/test/test_deque.py

@@ -479,6 +479,15 @@ class TestSubclass(unittest.TestCase):
         d = None
         self.assertRaises(ReferenceError, str, p)
 
+    def test_strange_subclass(self):
+        class X(deque):
+            def __iter__(self):
+                return iter([])
+        d1 = X([1,2,3])
+        d2 = X([4,5,6])
+        d1 == d2   # not clear if this is supposed to be True or False,
+                   # but it used to give a SystemError
+
 #==============================================================================
 
 libreftest = """