This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: ignored exceptions in generators (regression?)
Type: behavior Stage:
Components: Interpreter Core Versions: Python 2.7, Python 2.6
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: Nosy List: benjamin.peterson, doughellmann, pitrou
Priority: high Keywords:

Created on 2008-10-04 15:21 by benjamin.peterson, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (3)
msg74314 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2008-10-04 15:21
Given this code:

def f():
    for i in f():
        yield i

for i in f(): print i

2.6 gives:
Exception RuntimeError: 'maximum recursion depth exceeded in
__subclasscheck__' in <type 'exceptions.RuntimeError'> ignored
Exception RuntimeError: 'maximum recursion depth exceeded while calling
a Python object' in <type 'exceptions.RuntimeError'> ignored
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
...
  File "<stdin>", line 2, in f
RuntimeError: maximum recursion depth exceeded

2.5 and 3.0 do not have this problem.
msg74371 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2008-10-06 13:45
This is not specific to generators, this is due to the fact that a lot
of recursion checks have been added all over the place. When an internal
function designed to ignore exceptions (for example
PyErr_GivenExceptionMatches()) encounters such a recursion overflow, it
ignores it and prints it out. Such a function designed to ignore
exceptions can perfectly be called after a recursion overflow has
already happened, and that's what you witness here: the first
RuntimeError is raised, and soon enough that exception is given to
PyErr_GivenExceptionMatches() (perhaps because `for` has to detected
StopIteration's) where the recursion count overflows again
(`__subclasscheck__` can incur recursion so there is a recursion guard),
and the subsequent exception is ignored and printed out.

2.5 doesn't have the problem because many recursion checks have been
added between 2.5 and 2.6.

3.0 doesn't have the problem because its recursion checking code tries
to be smart (but it has other problems).

See the message I've sent to python-dev some time ago:
http://mail.python.org/pipermail/python-dev/2008-August/082106.html
msg75925 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2008-11-16 03:46
Well, I'll just cross my fingers then. :)
History
Date User Action Args
2022-04-11 14:56:40adminsetgithub: 48290
2009-05-28 18:32:58doughellmannsetnosy: + doughellmann
2008-11-16 03:46:10benjamin.petersonsetstatus: open -> closed
resolution: wont fix
messages: + msg75925
2008-10-06 13:45:33pitrousetnosy: + pitrou
messages: + msg74371
2008-10-04 15:21:42benjamin.petersonsettype: behavior
components: + Interpreter Core
2008-10-04 15:21:28benjamin.petersoncreate