Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
I'm no expert in recursion checking inside the Python interpreter, but
looking at the code for _Py_CheckRecursiveCall(), I don't think it is a
bug but a feature.
Here how I understand it. When the recursion level exceeds the normal
recursion limit (let's call the latter N), a RuntimeError is raised and
the normal recursion check is temporarily disabled (by setting
tstate->overflowed) so that Python can run some recovery code (e.g. an
except statement with a function call to log the problem), and another
recursion check is put in place that is triggered at N+50. When the
latter check triggers, the interpreter prints the aforementioned
Py_FatalError and bails out.
This is actually what happens in your example: when the normal recursion
limit is hit and a RuntimeError is raised, you immediately catch the
exception and run into a second infinite loop while the normal recursion
check is temporarily disabled: the N+50 check then does its job.
Here is a simpler way to showcase this behaviour, without any nested
exceptions:
def f():
try:
return f()
except:
pass
f()
f()
Can someone else comment on this?
----------
nosy: +pitrou
_______________________________________
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3555>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
