-
-
Notifications
You must be signed in to change notification settings - Fork 30.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GH-99749: Add optional feature to suggest correct names (ArgumentParser) #124456
base: main
Are you sure you want to change the base?
Conversation
@rhettinger Looks like CI is all green now! |
Just wondering, if you choose to make this False by default, then effectively application devs will not be able to use this new feature until they drop support for Python <3.14 (unless I am mistaken?). Maybe it would be "nicer" to make this opt-out instead of opt-in? If I understood correctly, the main argument against this in the original PR was a concern about adding more import time to argparse module from |
Right, this would be a new, opt-in feature in 3.14 onward. If we instead made it opt-out, it could unexpectedly change outputs that users depend on (e.g., for tests or other workflows). In general, I think we should be somewhat conservative with changes to argparse to prevent breaking changes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
This PR slightly conflicts with #117766. After merging one of them, the other one should be updated. I am not sure what of them should be merged first.
A fix should definitely precede a new feature. |
This PR carries #99773 forward with the original author's go-ahead (thanks @abdulrafey38!). This adds the ability for
ArgumentParser
to offer suggestions for mistyped argument choices or subparser names. This PR adds this as an optional feature via thesuggest_on_error
param (default:False
).I have opted to not make this configurable at the subparser or argument level and instead at the parser level to keep this simple. We could consider additional granularity but I'm not convinced that this is required at this time.
choices
argument #99749📚 Documentation preview 📚: https://cpython-previews--124456.org.readthedocs.build/