| msg25840 - (view) |
Author: Steve Alexander (stevea_zope) |
Date: 2005-07-21 22:22 |
| 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] |
|
|
| msg25841 - (view) |
Author: Raymond Hettinger (rhettinger) *  |
Date: 2005-08-21 11:10 |
| 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(). |
|
|
| msg25842 - (view) |
Author: Steve Alexander (stevea_zope) |
Date: 2005-09-16 09:02 |
| 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. |
|
|
| msg69965 - (view) |
Author: Karen Tracey (kmtracey) |
Date: 2008-07-18 18:35 |
| 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.) |
|
|
| msg69973 - (view) |
Author: Georg Brandl (georg.brandl) * |
Date: 2008-07-18 18:51 |
| Reopening. For reference, the revision in which Raymond supposedly fixed this is r39305. |
|
|
| msg69978 - (view) |
Author: Karen Tracey (kmtracey) |
Date: 2008-07-18 18:58 |
| 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 "", line 1, in File "", line 6, in __len__ KeyboardInterrupt >>> It just seems to have regressed in 2.6. |
|
|
| msg69979 - (view) |
Author: Georg Brandl (georg.brandl) * |
Date: 2008-07-18 19:00 |
| I'm sorry, my use of "supposedly" was wrong here. |
|
|
| msg70093 - (view) |
Author: Georg Brandl (georg.brandl) * |
Date: 2008-07-20 21:44 |
| 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? |
|
|
| msg70364 - (view) |
Author: Benjamin Peterson (benjamin.peterson) * |
Date: 2008-07-28 17:08 |
| Raymond, can you comment? |
|
|
| msg70366 - (view) |
Author: Raymond Hettinger (rhettinger) * |
Date: 2008-07-28 18:56 |
| 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. |
|
|
| msg79873 - (view) |
Author: Alyssa Coghlan (ncoghlan) * |
Date: 2009-01-14 20:19 |
| Reassigning to Raymond (as per the thread at http://mail.python.org/pipermail/python-dev/2009-January/085030.html) |
|
|
| msg79891 - (view) |
Author: Raymond Hettinger (rhettinger) * |
Date: 2009-01-15 07:45 |
| 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. |
|
|
| msg79914 - (view) |
Author: Raymond Hettinger (rhettinger) * |
Date: 2009-01-15 19:31 |
| Anyone else want to pick this up from here? |
|
|
| msg79922 - (view) |
Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * |
Date: 2009-01-15 22:49 |
| 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. |
|
|
| msg81005 - (view) |
Author: Raymond Hettinger (rhettinger) * |
Date: 2009-02-02 21:54 |
| Thanks for the review. Fixed in r69227. |
|
|