I don't think this should be done.

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?

Image links don't work in the survey.

Thanks, fixed.

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.

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.

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.

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):

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:

• "In argparse, I've always wanted a way to make colored help text like those of poetry and pipenv." python/cpython#86189
• "A drop-in replacement would be nice so I don't have to switch from argparse to something else in all my projects." Textualize/rich#2258
• "I'd also like to know how to properly color the --help output with colorama." https://stackoverflow.com/questions/69980467/argparse-remove-whitespace-after-flags-in-help-and-colorizing-help-output-wit

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!

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.