The example below shows that list(f) swallows the
KeyboardInterrupt.

It swallows any other exception too, such as
MemoryError or application-specific ConflictErrors.

I think the "get the length of the object" optimisation
should catch only AttributeError and TypeError.

>>> class F(object):
...     def __iter__(self):
...         yield 23
...     def __len__(self):
...         print "len called.  raising Keyboard
Interrupt."
...         raise KeyboardInterrupt
...
>>> f = F()
>>> list(f)
len called.  raising Keyboard Interrupt.
[23]

Logged In: YES 
user_id=80475

Okay, fixed in several places.  This little fragment
occurred in a number of places including code listextend(),
map(), zip(), filter(),  and PySequence_Tuple().  

Logged In: YES 
user_id=492001

Interestingly, I just saw some code that was causing a
problem in the SchoolTool project.  It had a __len__ method
that used list(self), causing great slowness without this
fix, and a RuntimeError "maximum recursion depth exceeded"
with this fix.

This behavior has reappeared in the 2.6 beta releases:

Python 2.6b2 (r26b2:65082, Jul 18 2008, 13:36:54) 
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class F(object):
...     def __iter__(self):
...         yield 23
...     def __len__(self):
...         print 'len called, raising KeyboardInterrupt'
...         raise KeyboardInterrupt
... 
>>> f = F()
>>> list(f)
len called, raising KeyboardInterrupt
[23]

Should a new bug be opened for this?  (I can't find one but I'm not too
experienced searchign Python's bug tracker.)

Reopening. For reference, the revision in which Raymond supposedly fixed
this is r39305.

Thanks for responding.

It had been fixed.  2.4/2.5 behave like so:

Python 2.5.1 (r251:54863, Mar  7 2008, 04:10:12) 
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class F(object):
...     def __iter__(self):
...         yield 23
...     def __len__(self):
...         print 'len called, raising KeyboardInterrupt'
...         raise KeyboardInterrupt
... 
>>> f = F()
>>> list(f)
len called, raising KeyboardInterrupt
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 6, in __len__
KeyboardInterrupt
>>> 

It just seems to have regressed in 2.6.

I'm sorry, my use of "supposedly" was wrong here.

The problem is in _PyObject_LengthHint which calls len(o) and masks all
exceptions from it. Its comments says "This function never fails.
Accordingly, it will mask exceptions raised in either method."

Would it be better to at least not mask BaseExceptions?

Raymond, can you comment?

Georg's suggestion seems reasonable.  Alternatively, you can just catch 
AttributeError or TypeError.

Lowering the priority to normal and marking as unresolved.  At some 
point, it would be nice to review the whole code base to see if other 
calls to PyErr_Clear() are too aggressive.  In that review, perhaps a 
more clean and general solution with present itself.

Reassigning to Raymond (as per the thread at
http://mail.python.org/pipermail/python-dev/2009-January/085030.html)

Here's a patch that fixes-up length_hint and it's internal callers.

I think there are plenty of other places that also swallow exceptions
but will leave those for someone who wants to look at every instance of
PyErr_Clear() to see if it has been restricted to some small group of
exceptions.

Anyone else want to pick this up from here?

In _PyObject_LengthHint() code, at the line:
    if (ro == NULL && PyErr_Occurred()) {
It seems that PyErr_Occurred() is not useful and is always true when the 
previous PyObject_CallMethodObjArgs() returned NULL.

Otherwise the patch is fine to me.

Thanks for the review.
Fixed in r69227.