Skip to content

Support options with optional arguments #126374

Closed

Description

@serhiy-storchaka

Feature or enhancement

GNU getopt supports options with optional arguments. For example GNU grep can be used with option --color=auto and with just --color. Unix getopt does not need it, because it stops after encountering first nonoption argument, but GNU getopt needs it to support options intermixed with positional arguments. getopt.gnu_getopt() needs it for the same reason.

Neither optparse nor argparse directly support such kind of optional arguments. It can be supported in optparse with custom callback, but support of optional arguments in argparse is non-standard. In future I'm planning to add support of such kind of optional arguments in argparse, and maybe in optparse.

Linked PRs

Activity

  1. added a commit that references this issue on Nov 3, 2024
  2. added
    stdlibStandard Library Python modules in the Lib/ directory
    on Nov 3, 2024
  3. removed
    3.14bugs and security fixes
    on Nov 6, 2024
  4. added a commit that references this issue on Nov 11, 2024
  5. vbrozik commented on Nov 13, 2024

    @vbrozik

    @serhiy-storchaka Thank you for implementing this but is anyone using the getopt module in a new code? Is the feature still planned to be implemented for argparse?

    Since Python 3.13 the getopt module is soft-deprecated:

    Deprecated since version 3.13: The getopt module is soft deprecated and will not be developed further; development will continue with the argparse module.

  6. serhiy-storchaka commented on Nov 13, 2024

    @serhiy-storchaka
    MemberAuthor

    The Python implementation of getopt should be as powerful and flexible as the C implementation. This will help to port programs from other programming languages to Python. This feature was in the TODO list since beginning.

    This feature will also be added in argparse, I just haven't decided on one of the three interface options yet (special nargs value, new add_argument() option, or the part of a new argparse mode). I will decide after implementing that new mode.

    I thing that options with optional argument can be supported in optparse by using a custom callback. I am not sure whether a more direct support is needed.

    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.

  7. added a commit that references this issue on Dec 8, 2024
  8. mhsmith commented on Dec 18, 2024

    @mhsmith
    Member

    Neither optparse nor argparse directly support such kind of optional arguments.

    Isn't this supported by argparse's nargs='?'?

  9. serhiy-storchaka commented on Dec 18, 2024

    @serhiy-storchaka
    MemberAuthor

    No, argparse's nargs='?' has different semantic. In argparse, --color=auto and --color auto are the same. The value can only be omitted if the option is at the end of the command line or followed by other option or --, e.g. --color --recursive auto or --color -- auto.

  10. added a commit that references this issue on Jan 12, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    3.14bugs and security fixesstdlibStandard Library Python modules in the Lib/ directorytype-featureA feature request or enhancement

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions