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.

Author pitrou
Recipients benjamin.peterson, pitrou
Date 2008-10-06.13:45:32
SpamBayes Score 1.267356e-09
Marked as misclassified No
Message-id <1223300764.72.0.0791907253307.issue4040@psf.upfronthosting.co.za>
In-reply-to
Content
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
History
Date User Action Args
2008-10-06 13:46:04pitrousetrecipients: + pitrou, benjamin.peterson
2008-10-06 13:46:04pitrousetmessageid: <1223300764.72.0.0791907253307.issue4040@psf.upfronthosting.co.za>
2008-10-06 13:45:33pitroulinkissue4040 messages
2008-10-06 13:45:32pitroucreate