Options for colorizing the output.
Opened this issue · 9 comments
I just wanted to show you what I did, and secondly get your opinion on an enhancement. See https://github.com/sentientmachine/better-exceptions/blob/master/README.md
I like it when the line numbers pop out so it draws my eye, so I did that in the link above.
Enhancement suggestion: these python errors/warnings are all well documented and well known. What if better-exceptions had a feature that would read the error message, read the code that committed it and return a more easily understood error message and a quick one or two line code snippet to show you what isn't allowed.
It would be most helpful for cryptic bugs that bubble-up implementationitis when you use numpy functions incorrectly and you get blasted in the face with incomprehensible error messages. Like for example matrix multiplications that say you can't invert a singular matrix. It gives you a 5 line refresher on why singular matrices can't be inverted.
Colorization of file / line / function would be great in my opinion. This seems related to what was proposed in #32 about implementing tbvaccine's enhancements.
The complications arise from the fact that to color the stacktrace like this, it must be parsed once it has been formatted using traceback.format_list(). I avoid you technical details, but for having implemented it in a personal fork, I can say that this is not a very elegant solution. But it is possible, of course.
Improved error messages is a whole other beast. There seems to be a lot of cases to deal with.
Wow that is really cool, it looks like he has a marker to mark the current directory and files beneath as the only files that get colorized.
Yes, this is what is done here.
It iterates through the lines of the formatted exception, if the line matches the file regex, it extracts the filename and checks heuristically if it belongs to the user or not.
OT:
That's really good, I've been wanting something that distinguishes visually between the users code and the systems code for a while.
If this can be implemented elegantly then I'm all for it. :)
Well, the obvious way is to use a regex substitution on the formatted stacktrace. That's not very elegant. But I can't see any other solution.
I've been wanting something that distinguishes visually between the users code and the systems code for a while.
This would be really helpful.
Is tbvacine a completely different project, or a fork of this, at first I was having trouble working out how the code relates, but I guess it's to show a possible implementation ?
finding the file, line and function probably wants to be separate from the actual colouring - to make all sorts of things easier (e.g. different colour themes, or adding links to files).
Irrespective of how colourization would work, any idea where in the code this should go ?
Is tbvacine a completely different project, or a fork of this
Entirely different, no relation.
Irrespective of how colourization would work, any idea where in the code this should go ?
If we're talking about the image OP provided (were elements of the traceback are very clearly distinguished), I would imagine somewhere near the existing color support. If you want to formalize how the coloring system works, then go for it. A lot of the existing logic is kind of hairy since some of it has been copied from the internals, and the original implementation was extracted from a programming language compiler I was writing at the time (meaning it wasn't intended to be its own package at first, so 'cleanliness' wasn't priority no. 1 😅).
Feel free to take some liberties.
What if better-exceptions had a feature that would read the error message, read the code that committed it and return a more easily understood error message and a quick one or two line code snippet to show you what isn't allowed.
I actually think this is out of scope for this package. As the OP has described it (unless I'm mistaken), they're asking for replacing exceptions with an entirely new format that is "newbie friendly", giving a succinct explanation of the problem.
Not only is that really hard to achieve, it's not something I'd ever dare mess with - tracebacks are verbose for a reason. They aren't there to help you learn Python, they're there to help you fix a problem with your code.
Highlighting important traceback elements is a 👍, replacing tracebacks altogether with something watered down is a non-starter for me and thus a 👎.