Repository navigation
Use color to highlight error locations #112730
Description
This has several advantages:
- Will help a lot with readability as parsing the error lines is easier if color highlights the error ranges.
- In the future we can optionally (via config) drop the ranges and only use color, recovering back the extra lines that the carets are taking.
- All the cool kids are doing it: This feature has already been successfully implemented in various tools. It has proven to be an effective aid for developers in quickly identifying the source and location of errors.
Control features:
- The feature will use 16 ANSI color scapes so the actual color is configured via the terminal emulator.
- Users can set the following env vars to control it (in the following order):
PY_COLORS=1activates the feature (used by pytest: https://github.com/pytest-dev/pytest/blob/022f1b4de546c8b3529e071965555888ecf01cb4/src/_pytest/_io/terminalwriter.py#L28)PY_COLORS=0deactivates the featureNO_COLOR=1deactivates the featureFORCE_COLOR=1activates the feature- Feature is deactivated if terminal is not a tty or if
TERMis set todumb.
Linked PRs
- gh-112730: Use color to highlight error locations #112732
- gh-112730: Update docs for colour env vars #112837
- gh-112730: Make the test suite resilient to color-activation environment variables #117672
- gh-112730: use keyword only argument for colorize #118086
- gh-112730: Respect tests that require environment variables with no-colorize fixes #118288
Activity
pythongh-112730: Use color to highlight error locations
pythongh-112730: Use color to highlight error locations
pythongh-112730: Use color to highlight error locations
pythongh-112730: Use color to highlight error locations
pythongh-112730: Use color to highlight error locations
pythongh-112730: Use color to highlight error locations
pythongh-112730: Use color to highlight error locations
pythongh-112730: Use color to highlight error locations
hugovk commentedon Dec 5, 2023
This looks really good, thanks!
Perhaps something for a followup, can we customise the colouring a bit?
PR #112732 right now:
GitHub / MagicPython
GitHub markdown (with
pytbafter the triple backticks):(GitHub screenshot)
(Uses https://github.com/MagicStack/MagicPython for Python tracebacks: https://github.com/github-linguist/linguist/blob/master/vendor/README.md)
Sphinx / pygments
Sphinx with
.. code-block:: pytb, for example on the PEPs repo:(Uses Pygments' Native style)
pablogsal commentedon Dec 5, 2023
Yup, see #112732 (comment).
I want to explore customization options AFTER we land the basic version first. EDIT Or are you referring to customizing the coloring as "adding more colors"?
On the other hand, are you suggesting to also colorize the name of the exception, the file, the number and the Traceback text?
I have been told that yellow and cian are really bad for light mode, so we should do something else there.
pablogsal commentedon Dec 5, 2023
@hugovk What about like this?
hugovk commentedon Dec 5, 2023
I wasn't thinking about allowing the user to customise them (although that's something to consider) but about having different colours for the different elements (exception name, file, etc).
Yes, we should check the contrast is good for both light and dark modes.
The GitHub colours (ignoring the plain black/white text) look the same for each mode and display well for both:
edit: and the blues are different, but you get the idea :)
pablogsal commentedon Dec 5, 2023
I am quite colorblind myself 😅 Do you mind telling me what colors are supposed to be every piece? As in "filename is ..., line number is ...., function name is ..., source code is ..., error location is ...)
19 remaining items
pablogsal commentedon Apr 8, 2024
Maybe we could just add a support decorator that just does the appropriate monkey patching in the colorise function to avoid being affected by the force colours variable. To avoid regressions, setting FORCE_COLORS in GH actions sounds like a good idea.
pablogsal commentedon Apr 8, 2024
I think if we don't do this it's going to be a full pain for us and a lot of users that have the variable set in CI and are running subprocesses in tests
pythongh-112730: Make the test suite relient to color-activation envi…
pythongh-112730: use keyword only argument for colorize
pythongh-112730: use keyword only argument for colorize
gh-112730: Make the test suite resilient to color-activation environm…
encukou commentedon Apr 25, 2024
#117672 broke several stable buildbots, see e.g. here. As Jakub noted they seem to be
--enable-sharedbuilds that rely onLD_LIBRARY_PATHto find libpython.Do you have time to look into this?
pablogsal commentedon Apr 25, 2024
I will look into this today. We can revert in the meanwhile if you wish
pythongh-112730: Respect tests that require environment variables wit…
gh-112730: Respect tests that require environment variables with no-c…
pablogsal commentedon Apr 26, 2024
I think this will be fixed by #118288
hugovk commentedon Jun 15, 2024
#118288 has been merged, closing.
pythongh-112730: Use color to highlight error locations (pythongh-112732
pythongh-112730: Update docs for colour env vars (python#112837)