@willmcgugan i think this is beautiful and I want things like it everywhere.
@willmcgugan yes please! I did something similar for my library, and I think it's a very nice dx https://patrick.wtf/posts/better-errors-in-strawberry-graphql
@willmcgugan it's a bit too subtle for me to realise. 😅
Plus, I think there's ~ and ^ symbols in the default tracebacks which would be good to reflect.
@willmcgugan Honest truth - While I apreciate the engineering effort that goes into this kind of feature, and I appreciate that I'm just one opinion - I'd very much like tools to *stop "fixing" tracebacks*. My biggest complaint about both Rich and Pytest as tools is the way they "enhance" stack traces. I *have* the code sitting *right here*. I can *find* the context around "line 130". I don't need my console filled with all the context of line 130, and all the context calling line 130, etc
@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.
@freakboy3742 But Rich.traceback is very configurable. You can configure a single line of code if you wish.
You can also remove framework files, so you only see "your" code.
@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.
@willmcgugan @freakboy3742 there are often cases where I want to see local variables. Not sure how compact this could be made (regular traceback + maybe local vars only appearing in the mentioned lines?) through customization 😊
@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".
@willmcgugan @freakboy3742 While rich.traceback might be configurable, it's the code author who configures it, not the user.
As a tool used responsibly to give the user *choices* about how exceptions are displayed, it's fine. As a format imposed on users by application authors, much less so. (This is just as true of *any* traceback formatting utility, of course...)
@freakboy3742 re logs. Rich tracebacks shouldn't ever make it in to logs for just that reason. They won't if you are using standard logging tools.
@pfmoore @freakboy3742 Depending on what you mean by user her. If the user is a dev working on a framework, it should be left up to the user to call `traceback.install()`.
If the user is a user of an app, then they probably shouldn't be seeing any kind of traceback.