Repository navigation
argparse.HelpFormatter color argument removed in 3.15.0a3 without deprecation #142928
Description
Activity
- addedtype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error
on Dec 18, 2025 - addedstdlibStandard Library Python modules in the Lib/ directoryStandard Library Python modules in the Lib/ directory3.15bugs and security fixesbugs and security fixes
on Dec 18, 2025 Thanks for the report! Ah yeah, you're right, we should warn about this.
The color parameter on HelpFormatter was never documented and didn't work correctly when users also set color on the parser (see #139862), so it needed to be removed. However, I should have added a deprecation warning rather than removing it outright. I've opened a PR: #142928
The color parameter on HelpFormatter was never documented
More to the point, HelpFormatter itself was never documented, so we could just remove the parameter, but a depreciation is fine.
HelpFormatter itself was never documented, so we could just remove the parameter
FWIW I don't agree that undocumented means no backwards compatibility guarantees. https://peps.python.org/pep-0387/#backwards-compatibility-rules explicitly says "Anything documented publicly as being private" is excluded, not "Anything not documented".
EDIT: The class in question is actually documented as being private other than the name.
More to the point, HelpFormatter itself was never documented, so we could just remove the parameter, but a depreciation is fine.
I believe these API changes also need to be kept in sync with typeshed.
https://github.com/python/typeshed/blob/main/stdlib/argparse.pyi
AFAIR, the formatter classes have a docstring saying that only the name of the class is public. So instantiating formatters was never part of the public API.
You are right and I was wrong. Mea culpa.
Considering I found this by a real failure, I still think the depreciation warning is benefitial to have either way.
Personally there are some arguments I would love to be officially supported such as the max help position etc, that is, at least the signature to be documented.
It does not make much sense to have default values otherwise.. and so I would also think a warning should be emitted for "color".
I discussed this more in depth with @hugovk, and after stewing on this a bit more, I don't think it's worth going through the full deprecation cycle to sidestep fundamentally broken behaviour and am inclined to close the PR I opened earlier this morning. Again, this was never documented and never worked - passing the parameter on HelpFormatter was broken from the get go. This change in behaviour is actually exposing buggy user code.
Reacted by Hugo van Kemenade- addedpendingThe issue will be closed if no feedback is providedThe issue will be closed if no feedback is provided
on Dec 18, 2025 Not sure if it changes the calculus on this, but I ran into breakage related this over in
buildon Python 3.15, see pypa/build#1067.EDIT: never mind, this has already been fixed in
build.Reacted by Savannah Ostrowski
Metadata
Metadata
Assignees
Labels
Projects
- StatusShow more project fieldsDoc issues
Bug report
Bug description:
As reported in #142274 (comment) I belive the chnage introduced an unintended API break:
In particular, this breaks pypa/build before pypa/build#962 -- but it can break other users as well. I believe we cannot simply remove the argument without making it a breaking change.
CPython versions tested on:
3.15
Operating systems tested on:
Linux
Linked PRs
coloronHelpFormatter#142946