Options for colorizing the output. about better-exceptions HOT 9 OPEN

OT:

That's really good, I've been wanting something that distinguishes visually between the users code and the systems code for a while.

from better-exceptions.

If this can be implemented elegantly then I'm all for it. :)

from better-exceptions.

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.

from better-exceptions.

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.

from better-exceptions.

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.

from better-exceptions.

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.

from better-exceptions.

I've been wanting something that distinguishes visually between the users code and the systems code for a while.

This would be really helpful.

from better-exceptions.

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 ?

from better-exceptions.

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 👎.

from better-exceptions.