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 Dennis Sweeney
Recipients Dennis Sweeney, ronaldoussoren, xxm
Date 2020-11-30.09:04:41
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1606727081.89.0.516917603457.issue42509@roundup.psfhosted.org>
In-reply-to
Content
sys.getrecursionlimit() returns whatever was passed to the most recent call of sys.setrecursionlimit(...), with some system default (here 1000).

Catching a RecursionError might be fine sometimes, but the issue is that Program 1 catches a RecursionError *and then keeps recursing more* rather than stopping.

I think it might have to be the responsibility of the Python user to make sure that if a RecursionError is to be caught, that the program can recover without making things much worse. It's my understanding that the extra buffer of +50 is to make sure that the programmer has room to stop the overflow and do any necessary cleanup [1].

If no attempt is made to clean up, then it seems reasonable to me that Python should crash, unless there's some idea of what could happen that I'm missing. The interpreter could allow arbitrary recursion during the cleanup until the C stack overflows, but that sort of defeats the point of the recursion checker. It could raise some new ExtraSuperRecurionError, but that doesn't fix anything: what if *that* error is caught ;) ?

[1] to get back to a recursion depth lower than some lower threshold: https://github.com/python/cpython/blob/master/Include/internal/pycore_ceval.h#L98
History
Date User Action Args
2020-11-30 09:04:41Dennis Sweeneysetrecipients: + Dennis Sweeney, ronaldoussoren, xxm
2020-11-30 09:04:41Dennis Sweeneysetmessageid: <1606727081.89.0.516917603457.issue42509@roundup.psfhosted.org>
2020-11-30 09:04:41Dennis Sweeneylinkissue42509 messages
2020-11-30 09:04:41Dennis Sweeneycreate