Repository navigation
Use color to highlight error locations #112730
Description
Activity
- added 6 commits that reference this issue
on Dec 4, 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):Traceback (most recent call last): File "/Users/hugo/github/python/cpython/main/1.py", line 1, in <module> 1/0 ~^~ ZeroDivisionError: division by zero
(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)
Perhaps something for a followup, can we customise the colouring a bit?
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.
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 :)
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 ...)
Reacted by Hugo van Kemenade19 remaining items
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.
Reacted by Alex WaygoodI personally think it's very useful for Python to use the same env vars that are being increasingly widely adopted elsewhere. So I suppose I lean towards changing
-Eso that it also ignores theFORCE_COLORvariable.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
- added a commit that references this issue
on Apr 24, 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?
I will look into this today. We can revert in the meanwhile if you wish
This has several advantages:
Control features:
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 featureTERMis set todumb.Linked PRs