Skip to content
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

Open
wants to merge 49 commits into
base: main
Choose a base branch
from

Conversation

savannahostrowski
Copy link
Member

@savannahostrowski savannahostrowski commented Sep 24, 2024

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 the suggest_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.


📚 Documentation preview 📚: https://cpython-previews--124456.org.readthedocs.build/

@savannahostrowski savannahostrowski added stdlib Python modules in the Lib dir 3.14 new features, bugs and security fixes labels Sep 24, 2024
Lib/argparse.py Outdated Show resolved Hide resolved
@rhettinger rhettinger self-assigned this Sep 24, 2024
@savannahostrowski
Copy link
Member Author

@rhettinger Looks like CI is all green now!

@danielhollas
Copy link
Contributor

This PR adds this as an optional feature via the suggest_on_error param (default: False).

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 difflib, but since it is now imported lazily perhaps that is no longer such an issue?

@savannahostrowski
Copy link
Member Author

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.

Lib/argparse.py Outdated Show resolved Hide resolved
Lib/argparse.py Outdated Show resolved Hide resolved
Lib/argparse.py Outdated Show resolved Hide resolved
Lib/argparse.py Outdated Show resolved Hide resolved
Lib/argparse.py Outdated Show resolved Hide resolved
Lib/argparse.py Outdated Show resolved Hide resolved
Copy link
Member

@serhiy-storchaka serhiy-storchaka left a 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.

@rindeal
Copy link
Contributor

rindeal commented Sep 26, 2024

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.

@savannahostrowski savannahostrowski added the type-feature A feature request or enhancement label Oct 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3.14 new features, bugs and security fixes awaiting merge stdlib Python modules in the Lib dir type-feature A feature request or enhancement
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants