Repository navigation
Colorize exception notes #140049
Description
Activity
IMO, we shouldn't. Notes can be very long while exception messages are ususally shorter. I would find disruptive to have a fully colored wall of text (which may not necessarily be readable (I feel the purple not very readable no a dark theme if there is a very long text)).
I think we need more input here.
Reacted by Mikhail EfimovI see your point, let's wait for input from others. However, as for the colour, that can be configured. If you have a suggestion for it I am happy to apply it in the PR.
I think I agree with Bénédikt. An exception note is different from the exception message, and giving it the same color hurts that distinction (especially in exceptions that contain newlines).
I wouldn't be opposed to giving the note a different color, but what color would that be?
Here are all of the colours currently available in
_colorize.ANSIColors:
I think that the color for note should be optional.
It seems that it has conflict with my plan "exception_target" (what after the exception message is "exception_target" instead of "__notes__"):
If it finally be accepted, I will try to resolve my PR for it.
Even if we can configure colors, I don't like having a wall of text being colored, whatever color we choose. Sure we can disable the color itself for the given theme, but we currently have no way to properly configure themes in a configuration file.
As for "exception target" if this is something meant to be on any exception, this requires a PEP I think (but I do not see the needs of it since we can use notes..)
since we can use notes
In now "test_traceback", some tests get the last line of the exception message to get the exception message and test. However, after this change, it failed. So I try to use a new way that can just get the original message. And if the Exception has its original "__notes__" that not a list, we cannot add any note on it. The "exception target" is only for "TracebackException" instead of "BaseException" to get the Exception message or the other special handle message while handle the original Exception
Let us discuss this separately on the original issue. I do not think it is relevant to the colorization of notes.
Do you have some examples of exception notes that are walls of text?
Do we have any stats on the variation of exception note length in open source projects?
Reacted by Stan UlbrychWell.. we recently improved an exception in Generic which I consider wall of text (more than one sentence is already painful to read if it is entitely colored for me). I see notes as something apart from the exception message and thus semantically different. The choice of the notes' color may also be different depending on the exception (maybe the note should be colored in red for important ones, and yellow otherwise for instance, but that is up to the user)
The question is that if I add my ANSI color in my import part of the note then use "\033[0m" the text after it won't be colorized by the default color. In fact, the custom exception often use
raiseto raise and at that time user cannot contacttraceback.TracebackExceptionortraceback.print_excexcept they use them to print it instead of raise it, so I think that the note should be only colorized by user.Kickstarting this again, here's the note in bold blue and cyan, either looks good to me:
Blue is harder for me to read because my background is between gray and blue. I am still not really convinced by the fact that we add colors everywhere but blue/cyan is better than magenta to separate notes from exception message at least. I would lean towards cyan or light cyan though or even intense white if it is not already taken.
I do think we need more themes than just light/dark for accessibility reasons though but let's push that one in the alpha to see if people are happy with the color choices. It is easy to change the color afterwards.
They are now cyan, closing.
Reacted by Hugo van Kemenade- added a commit that references this issue
on Mar 23, 2026
Feature or enhancement
Proposal:
For example:
They are part of the traceback, I think it would make sense for them to be coloured like the error message.
I have a patch ready.
Has this already been discussed elsewhere?
This is a minor feature, which does not need previous discussion elsewhere
Links to previous discussion of this feature:
No response
Linked PRs
traceback.py#140051