GeezerVison is showing github.com — Add colour to `argparse` help · Issue #130645 · python/cpython
Add colour to argparse help #130645DescriptionFeature or enhancement
In Python 3.13 we added colour output to the new REPL, traceback and doctest, and in 3.14 to unittest, test.regrtest and calendar, that can also be controlled with the PYTHON_COLORS, NO_COLOR and FORCE_COLOR environment variables:
Let's add colour to argparse help output.
Survey
First, here's a survey of some other CLIs that use colour:
Survey
These fall into four groups:
- uv/cargo: green + cyan
- composer: yellow + green
- ruff/lsd/fd/gh: only bold
- typer/rich-cli: green + cyan + yellow
Prototypes
I've made prototypes of two of these (uv/cargo style, typer/rich-cli style), and another with blue + magenta similar to the 3.13 REPL/traceback.
Prototypes
| main
|
| 
|
| uv/cargo style
|
| 
|
| typer/rich-cli style
|
| 
|
| REPL style
|
| 
|
I think I prefer the typer/rich-cli style: the extra colour makes it easier to pick out the (green) short options from the (cyan) long options, and from their (green) arguments. And it should also be somewhat familiar to Python users who have used typer-based CLIs.
Linked PRs
Reacted by Tomas R., Adam Johnson, Hash, espdev, yihong, impervius and sedrubal Reacted by Bryan Kaplan Reacted by Sebastian Pipping and Erik Körner Activityrhettinger commented on Feb 27, 2025 I don't think this should be done. Reacted by M. Kocher and Bryan Kaplan Reacted by espdev, Josh Niec, sedrubal and malucart StanFromIreland commented on Feb 27, 2025 Image links don't work in the survey.
I'd vote for REPL style. It's not bombarding you with color and the magenta/purple is generally visible in all terminal styles.
Raymond could you please clarify why? We already have some color in the REPL and there are ongoing efforts to add more (#130472) so it seems people are generally in favor of color.
Edit: Seeing it now, I think the simple ruff style would be fine, what do you think @rhettinger, about a very simple coloring? Reacted by Srinivas Reddy Thatiparthy (తాటిపర్తి శ్రీనివాస్ రెడ్డి) hugovk commented on Feb 27, 2025
Image links don't work in the survey.
Thanks, fixed. AlexWaygood commented on Feb 27, 2025 Are you aware of the rich-argparse project (https://github.com/hamdanal/rich-argparse)? I use it in my typeshed-stats project, and it's very nice indeed. This is all I need to do to add colour to my argparse-based CLI in that project; everything else is just stdlib argparse. Reacted by M. Kocher and Maximilian Knespel sobolevn commented on Feb 28, 2025 I think that adding an option (which is off by default) is a good idea, but argparse must stay colorless by default, too many tests in the wild depend on it. rhettinger commented on Mar 2, 2025 If you end-up doing this over my objections (no major standard command-line tool does this), then it must be opt-in.
Also, the bulk of the code should be in a separate submodule that is only imported with needed. Start-up time is a critical issue for argparse. We've worked hard to avoid dependencies and to have a fast load time.
Also, the choice of colors really matters. Bad choices can impair usability for all users, or for users with the particular choice of light or dark backgrounds, or for users with vision issues including various kinds of color blindness. IPython is an example of a tool that made poor choices. When running ?? to look at source code against a black background, IPython displays operators like =, +, or parens in a dark blue that is very hard to read.
AFACIT, no group of users has ever requested this feature even though this is a heavy used, popular module. ISTM that the OP is doing this as part of a "sweep" across modules (such as unittest) without considering the whether the existing users of the module want or need this. rhettinger commented on Mar 2, 2025 Example of IPython's impaired readability with a poor choice of colors (the assignments, multiplications, and function calls are almost invisible and the docstring is challenging as well):
 Reacted by sobolevn and Maximilian Knespel hugovk commented on Mar 3, 2025
Are you aware of the rich-argparse project (hamdanal/rich-argparse)?
I wasn't, thanks for sharing. I think this would still be useful in the stdlib, for when you want to keep your dependencies to a minimum, and rich (plus its dependencies) is a fairly large package.
I think that adding an option (which is off by default) is a good idea, but argparse must stay colorless by default, too many tests in the wild depend on it.
Yes, it can be opt-in. And the existing PYTHON_COLORS and NO_COLOR env vars can also be used.
Start-up time is a critical issue for argparse. We've worked hard to avoid dependencies and to have a fast load time.
Agreed, this is important.
Also, the choice of colors really matters. Bad choices can impair usability for all users, or for users with the particular choice of light or dark backgrounds, or for users with vision issues including various kinds of color blindness. IPython is an example of a tool that made poor choices. When running ?? to look at source code against a black background, IPython displays operators like =, +, or parens in a dark blue that is very hard to read.
Absolutely, colour choice and accessibility is important. This is why I've surveyed popular existing tools and picked colours with good contrast, and none of those or my suggestsions use that blue. And @ambv is adding theming support this month, see: #130472 (comment).
AFACIT, no group of users has ever requested this feature even though this is a heavy used, popular module.
Here's some people wanting colour help in argparse:
I think the use of colour in third-party CLI replacements and rich-argparse also points to a demand.
ISTM that the OP is doing this as part of a "sweep" across modules (such as unittest) without considering the whether the existing users of the module want or need this.
Yes, now that we added colour support in 3.13 for the REPL and tracebacks, I'm looking to see where else we can improve the experience over plain monochrome output. Colour can be extremely helpful. unittest is a great example: coloured pytest output has long been very useful for finding the error(s) in long test logs. And it's now much easier to find errors in our own CI logs since unittest and test.regrtest have colour output.
Example of IPython's impaired readability with a poor choice of colors (the assignments, multiplications, and function calls are almost invisible and the docstring is challenging as well):
This is a good example of poor colour choice, thanks. This blue won't be used. As it happens, IPython 9.0.0 was released on Friday with much improved colours!
 Reacted by Zachary Ware, Adam Johnson, Michiel W. Beijen, Maximilian Knespel and malucart savannahostrowski commented on Mar 3, 2025 I'm +1 on this, if it's opt-in and ensures that we can ensure the startup time isn't impacted. In CLI tools that I've worked on in the past, we leaned heavily on the ANSI defined color presets when trying to guarantee accessibility/sufficient contrast. Reacted by Zachary Ware, CF Bolz-Tereick, Hugo van Kemenade, Adam Johnson and Łukasz Langa dreirund commented on Jul 10, 2026 It seems to me that coloured output of argparse --help output uses only one specific colour scheme which I cannot change.
And that colour scheme is barely readable on light themed terminals (e.g. black text on white background).
Setting environment varianle NO_COLOR to true does disable coloured output completetly and thus makes the output readable again, but that is not a good system wiede setting if colouring in general is wanted.
Many software that I install just uses argparse and so the --help output is not really readable on light terminals.
So I hereby need to be able to configure argparse's colour scheme by environment variables (or config file).
Is that possible? I did not find documentation on this.
If not, this is a feature request.
Regards! savannahostrowski commented on Jul 14, 2026 If the contrast is insufficient, that'd be a bug. We use ANSI color palette so things should adapt accordingly. Can you please file a new issue for this, since this is closed?
MetadataMetadataStatusShow more project fields
DevelopmentNo branches or pull requestsIssue actions
|
