Repository navigation
Errors raised in argparse are colorized when redirecting stderr to a file #139946
Description
Bug report
Bug description:
(Some) Errors raised in argparse will be colorized when redirecting stderr to a file.
Requirements:
- Errors redirected to a file are not colorized
- Unittest added to cover the case of error and redirecting of stderr
The most minimal example can be taken from calendar from the stdlib.
Works as expected with the color displayed correctly.
./python.exe -m calendar 2020 01 01Redirecting stderr
./python.exe -m calendar 2020 01 01 2> err
cat -v err
^[[1;34musage: ^[[0m^[[1;35mpython.exe -m calendar^[[0m [^[[32m-h^[[0m] [^[[32m-w ^[[33mWIDTH^[[0m] [^[[32m-l ^[[33mLINES^[[0m] [^[[32m-s ^[[33mSPACING^[[0m] [^[[32m-m ^[[33mMONTHS^[[0m] [^[[32m-c ^[[33mCSS^[[0m] [^[[32m-L ^[[33mLOCALE^[[0m] [^[[32m-e ^[[33mENCODING^[[0m] [^[[32m-t ^[[33m{text,html}^[[0m] [^[[32m-f ^[[33mFIRST_WEEKDAY^[[0m] ^[[32m[year]^[[0m ^[[32m[month]^[[0m
python.exe -m calendar: error: unrecognized arguments: 01Redirecting stdout will trigger the "correct" behavior
./python.exe -m calendar 2020 01 01 >out 2> err
(zatters-314) mkocher@zudio cpython % cat -v err
usage: python.exe -m calendar [-h] [-w WIDTH] [-l LINES] [-s SPACING]
[-m MONTHS] [-c CSS] [-L LOCALE] [-e ENCODING]
[-t {text,html}] [-f FIRST_WEEKDAY]
[year] [month]
python.exe -m calendar: error: unrecognized arguments: 01Observations
- Calling
can_colorize(file=None)assumes that the stdout is used whenfile=NoneThis implicit use ofcan_colorize()makes the code hard to reason about. - Calling
_set_coloralways assumes stdout. - Calling
self.print_usage(_sys.stderr)is breaking the assumption that stdout is being used. - global ENV var design choice make data flow in the code confusing to debug. Depending on how your argparse code is written and the pattern/style of raising errors, some errors raised are being colorized properly by traceback layer. For example, using
parser.error(...)orraise ArgumentTypeError(...)vs araise ValueError()within your application code. - I think users are going to be a bit confused when setting
ArgumentParser(color=False)and the error (might) still be colorized (because of the traceback layer determining if it should be colorized). It is documented that configure for traceback is done via ENV vars, but it's not particular clear how the config of these components overlap. - the specific error is not colorized (
python.exe -m calendar: error: unrecognized arguments: 01) but the usage is?
Stand alone example for debugging:
import sys
from argparse import ArgumentParser, ArgumentTypeError
def validate_lower(sx: str) -> str:
if any(not s.islower() for s in sx):
# this will be handled from within argparse.
# redirecting stderr will still have colorized ascii
raise ArgumentTypeError(f"{sx} contains a lowercase string")
return sx
def get_parser() -> ArgumentParser:
p = ArgumentParser(description="Testing", color=True)
f = p.add_argument
f('-m', '--max-records', type=int, help="Max number of records", required=True)
f('-n', '--name', type=validate_lower, help="User Name", required=True)
f('-t', '--trigger-error', action='store_true', help="Trigger error", required=False)
return p
def main(argv: list[str]) -> int:
p = get_parser()
pa = p.parse_args(argv)
if pa.trigger_error:
# will be colorized by traceback, must be configured by ENV vars to disable
raise ValueError("Trigger an error")
# this is also a common usage to raise an error
#p.error("Error case")
print(f"Completed running {pa}")
return 0
if __name__ == "__main__":
sys.exit(main(sys.argv[1:]))CPython versions tested on:
3.14
Operating systems tested on:
macOS
Activity
picnixz commentedon Oct 11, 2025
cc @savannahostrowski I don't know if you want a separate issue for that or an umbrella issue with argparse and colors.
savannahostrowski commentedon Oct 11, 2025
I'll take a look through this list and figure out what the best course of action is for each last this week. Thanks for filing this!
savannahostrowski commentedon Oct 25, 2025
Thanks for filing this! Points 1-3 will be addressed by #140495!
Regarding your points about environment variables, honoring environment variables is standard practice and necessary - many users rely on things like
NO_COLORbeing respected globally. We do document this in https://docs.python.org/3/library/argparse.html#color, which links to how you can control color in your local environment. However, I agree that the order of precedence could be documented more clearly.Regarding tracebacks, this is working as expected.
ArgumentParser(color=False)should only control argparse's output. If a user wants to disable color in their tracebacks, I'd expect them to set the correct environment variables to do that.Regarding point 6, good catch. The error/warning keywords should also be colorized for consistency.
GH-139946: Colorize error and warning messages in argparse (#140695)
pythonGH-139946: Colorize error and warning messages in argparse (pyt…
gh-139946: distinguish stdout or stderr when colorizing output in arg…
[3.14] GH-139946: Document argparse includes color codes when redirec…