-
-
Notifications
You must be signed in to change notification settings - Fork 31.1k
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
Support options with optional arguments #126374
Comments
@serhiy-storchaka Thank you for implementing this but is anyone using the Since Python 3.13 the
|
The Python implementation of This feature will also be added in I thing that options with optional argument can be supported in This module will be undeprecated (see #126180). It was not changed (except mass stdlib changes) in the last 15 years, so it is difficult to find an interested person for review. I asked for help and @gpshead reviewed #126393 which was created on the top of #126375. His comment did not question the feasibility of these changes, only the style of the tests code. Which I took as acceptance in principle. |
Isn't this supported by argparse's |
No, argparse's |
Feature or enhancement
GNU
getopt
supports options with optional arguments. For example GNUgrep
can be used with option--color=auto
and with just--color
. Unixgetopt
does not need it, because it stops after encountering first nonoption argument, but GNUgetopt
needs it to support options intermixed with positional arguments.getopt.gnu_getopt()
needs it for the same reason.Neither
optparse
norargparse
directly support such kind of optional arguments. It can be supported inoptparse
with custom callback, but support of optional arguments inargparse
is non-standard. In future I'm planning to add support of such kind of optional arguments inargparse
, and maybe inoptparse
.Linked PRs
The text was updated successfully, but these errors were encountered: