@willmcgugan These kinds of improvements turn a 5 line stack trace into a 5 page epic poem, making it a lot harder (for me) to interpret the context of an error; and if the "enhanced" error finds its way into a log - good luck with that, because the log is now unreadable. The presentation has been so strongly customized for a specific screen width that it's a nightmare to interpret.
I don't expect anything to change... but no, Sir, I don't like it :-)
@freakboy3742 Each to their own I guess, but I find the additional context very helpful.
Granted, 9 out of 10 times, all I need is the error and the most recent file / line, but for more complex errors I like to be able to go up the call stack and see code I may not even have open. The extra lines + locals help me figure out what conditions lead to the exception. And I can click on the path to open the IDE.
@willmcgugan @freakboy3742 I have to be honest, I agree with @freakboy3742. I'd hate this being what I typically see for a traceback. Maybe it's sometimes useful, but there's no way of knowing in advance *when* it's useful, and it's too "busy" IMO to be the default.
The heading is weirdly confusing as well - "most recent call last"? There's only one call shown. And showing more calls, in *that* format, would be far too verbose.
@pfmoore @freakboy3742 You don't have to use rich tracebacks. I intended it as a debugging aid. But some framework author do install it by default. I have considered implementing env vars to configure / disable rich tracebacks, but I have been reluctant to do that in the past because it seems out of the remit of a library.
The text "Traceback (most recent call last)" is lifted from the standard tracebacks. It is also displayed when there is a single frame. 🤷♂️
@willmcgugan @freakboy3742 I do hope enabling it by default, without giving the user a choice, doesn't become the norm 😟 If you do decide to add env vars, I'd strongly prefer "off by default, env var to enable".
