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

[Émanuel Barry]

I have been thinking, and especially after Nick’s comments, that it might be better to keep it as simple as possible to reduce the risk of errors happening while we’re printing the tracebacks. Recursive functions (that go deep enough to trigger an exception) are usually within one function, in the REPL, or by using __getattr__ / __getattribute__. Nice to have? Sure. Necessary? Don’t think as much.

 

I’m also a very solid -1 on the idea of prompting the user to do something like full_ex() to get the full stack trace. My rationale for such a change is that we need to be extremely precise in our message, to leave absolutely no room for a different interpretation than what we mean. Your message, for instance, is ambiguous. The fact it says that calls are hidden would let me think I just lost information about the stack trace (though that’s but a wording issue). As a user, just seeing "Call _full_ex() to print full trace." would be an immediate red flag: Crap, I just lost precious debugging information to save on lines!

 

Might be just me, but that’s my opinion anyway :)

 

-Emanuel

 

Example:
    File "<stdin>", line 1, in f
    File "<stdin>", line 1, in g
    [Mutually recursive calls hidden: f (300), g (360)]
    File "<stdin>", line 1, in h
    File "<stdin>", line 1, in f
    File "<stdin>", line 1, in g
   [Mutual-recursive calls hidden: f (103), g (200)]
  RuntimeError: maximum recursion depth exceeded
  [963 calls hidden. Call _full_ex() to print full trace.]

This rule is easily modified to, "have been seen at least three times before." For functions that recurse at multiple lines, it can print out one message per line, but maybe it should count them all together in the "hidden" summary.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160422/2bf752f5/attachment.html>