[Python-ideas] Shrink recursion error tracebacks (was: Have REPL print less by default)

[Émanuel Barry]

> 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