From Steven D'Aprano Sent: Wednesday, April 20, 2016 10:46 PM
We should not limit this to specifically *recursion* limits, despite the error message printed out, it is not just recursive calls that count towards the recursion limit. It is any function call.
In practice, though, it is difficult to run into this limit with regular non-recursive calls, but not impossible.
See my second comment
We can probably afford to cut out immediately as we notice the recursion,
No you can't. A bunch of recursive calls may be followed by non- recursive calls, or a different set of recursive calls. It might not even be a RuntimeError at the end.
See my first comment *wink wink* My proposal is so that we strip out repeated lines to avoid unnecessary noise, *not* to strip out everything thereafter! I agree that my wording was misleading, but I do want to keep all relevant information - only to strip out consecutive and identical lines. If there's a 20-call recursion in the middle of the stack for some odd reason (call itself with n+1 until n == 20 and then do something else?), some of it would be stripped out but the rest would remain. The core of my proposal is to enhance ability to read and debug large tracebacks, which most of the times will be because of recursive calls. We're shrinking tracebacks for recursive calls, and if that happens to shrink other large tracebacks as well, that's a useful side effect and should be considered, but that's not the core of my idea. If a one-size-fits-all solution works here, I'll go for that and avoid dumping yet another bucket of special cases (which aren't special enough to break the rules) into the code. There are already enough.
The point being, you cannot just stop processing traces when you find one repeated.
Yep, don't want that at all indeed. Thanks for your input Steven :) -Emanuel