I would like to submit the following test to be part of the test_iter.py test suite:

    def test_extends(self):
        # This test would break on an incomplete patch to listobject.c
        def gen():
            for i in range(500):
                yield i
        lst = [0] * 500
        for i in range(240):
            lst.pop(0)
        lst.extend(gen())

The history behind it is that I made a patch to listobject.c that obviously broke listextend(), but the tests did not catch it.  This was my failing test to improve my patch.  Regardless of what happens to the patch, I think it's a good idea to hammer on listextend() when it accepts an iterator, as it's a fairly tricky problem to extend a list when you do not know in advance how long it will be until the iterator gets exhausted.

From the comment ("This test would break on an incomplete patch to listobject.c") is not clear what exactly the test is supposed to check.
Probably the test should include some assert* or more comments if it is supposed to work but it might raise an error if there's something wrong.
Finally it would be better if you can provide a patch against trunk and attach it to the issue.

Per Ezio's suggestions, I added clearer comments and an assert, and now the attached diff applies to trunk.

Can you produce a more tightly focused test, the minimum code that would have segfaulted your change?

My proposed test is final.  Please either accept or reject it as is.  I assume it runs pretty quickly, so I am not sure what the cost fear is.  The benefit of accepting the test is that it would potentially catch bugs on changes to the implementation of list.