argparser's subparsers.add_parser() should accept an ArgumentParser

[cjerdonek]

BPO	17204
Nosy	@cjerdonek
Files	issue17204.py patch0.diff

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2013-02-14.07:01:07.036>
labels = ['type-feature', 'library']
title = "argparser's subparsers.add_parser() should accept an ArgumentParser"
updated_at = <Date 2014-10-10.04:35:04.656>
user = 'https://github.com/cjerdonek'

bugs.python.org fields:

activity = <Date 2014-10-10.04:35:04.656>
actor = 'paul.j3'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2013-02-14.07:01:07.036>
creator = 'chris.jerdonek'
dependencies = []
files = ['29916', '36858']
hgrepos = []
issue_num = 17204
keywords = ['patch']
message_count = 4.0
messages = ['182081', '187226', '204372', '228950']
nosy_count = 4.0
nosy_names = ['bethard', 'chris.jerdonek', 'paul.j3', 'Micka\xc3\xabl.Falck']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'needs patch'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue17204'
versions = ['Python 3.4']

[cjerdonek]

Currently, argparser's subparsers.add_parser() method (for adding sub-commands) takes the following input:

"This object has a single method, add_parser(), which takes a command name and any ArgumentParser constructor arguments, and returns an ArgumentParser object that can be modified as usual."

(from http://docs.python.org/dev/library/argparse.html#argparse.ArgumentParser.add_subparsers )

It would be nice if one could also pass an ArgumentParser object to add_parser(). This would allow the composition of parsers. For example, if a library exposed an ArgumentParser command-line API, one could expose that library's commands as a sub-command of the parent project's command-line API using add_parser().

[paulj3]

The 'subparsers' object has a _parser_class attribute that is normally set to the class of the parent parser. In the attached file I create a

    class CustomParser(argparse.ArgumentParser)

that makes a parser instance which copies all of the attributes of prototype parser.

    proto1 = argparse.ArgumentParser(prog='SUBPROG1')
    proto1.add_argument('--foo')
    subparsers._parser_class = CustomParser
    sub1 = subparsers.add_parser('cmd1', proto=proto1, help='parser based on proto1')

'sub1' is a functional copy of 'proto1'. I think this does what you want without changing the argparse code. There probably is a way of defining CustomParser (maybe its '__new__' method) so 'sub1' is actually 'proto1'. But the copy approach appears to work just fine.

[paulj3]

http://stackoverflow.com/a/20167038/901925
is an example of using _parser_class to produce different behavior in the subparsers.

    parser = ArgumentParser()
    parser.add_argument('foo')
    sp = parser.add_subparsers(dest='cmd')
    sp._parser_class = SubParser # use different parser class for subparsers
    spp1 = sp.add_parser('cmd1')
    spp1.add_argument('-x')
    spp1.add_argument('bar')
    spp1.add_argument('vars',nargs='*')

In this case the SubParser class implements a parse_intermixed_known_args method that handles that nargs='*' argument.

http://bugs.python.org/issue14191

It shouldn't be hard to add parser_class as a documented optional argument to add_subparsers.

[paulj3]

In the attached patch I modified 'add_parser' to take a 'parser' keyword parameter. If given, it is used as the parser, rather than create a new one. Thus an existing parser, or one created with a custom ArgumentParser class, could be used as a subparser.

In this sample script, a parent parser is used as subparser in 2 different ways - via the parent mechanism, and with this new add_parser parameter.

    parent = argparse.ArgumentParser()
    parent.add_argument('-f')
    parent.add_argument('bar')

    parser = argparse.ArgumentParser()
    sp = parser.add_subparsers(dest='cmd')
    p1 = sp.add_parser('cmd1', add_help=False, parents=[parent])
    p2 = sp.add_parser('cmd2', parser=parent)
    parent.add_argument('test')
    assert p2 is parent
    assert p1 is not parent
    print(parser.parse_args())

This change passes existing unittests. I don't think there are any backward compatibility issues.

[serhiy-storchaka]

You can pass the parents argument to add_parser(). This will create a new parser, but with actions, groups and defaults copied from the specified parsers. Will this solve the original problem?

There is an issue with reusing an existing parser (instead of copy) as a subparser -- you cannot override some parser parameters that should be overridden. For example, if you specify custom prog or usage for the main parser, you need to specify custom prog or usage for subparsers. The value of exit_on_error should be specified at the application level, not in library.

[doronbehar]

Hey! I just encountered the lack of this feature, and wanted to express my encouragement to include this feature.

I read the comments, and I also wanted to share a fuller example of one of the solutions suggested above (the solution I found most elegant):

#!/usr/bin/env python

import argparse

# Custom CalcParser subclass
class CalcParser(argparse.ArgumentParser):
    def __init__(self, **kwargs):
        super().__init__(**kwargs)
        self.add_argument('--input', type=str, help="Input file for calc operation")
        self.add_argument('--output', type=str, help="Output file for calc operation")

if __name__ == "__main__":
    # Top-level parser
    parser = argparse.ArgumentParser(description="Main CLI Application")
    subparsers = parser.add_subparsers(dest="command", required=True)
    show_parser = subparsers.add_parser("show", help="Handle show operations")
    # HACK.. See https://github.com/python/cpython/issues/61406#issuecomment-1093608161
    subparsers._parser_class = CalcParser
    calc_parser = subparsers.add_parser("calc", help="Handle calc operations")

    # Parse the arguments
    args = parser.parse_args()
    if args.command == "calc":
        print("Executing calc subcommand")
        print(args)
    elif args.command == "show":
        print("Executing show subcommand")
        print(args)

Trying to implement @serhiy-storchaka's idea with parents, it came out like this:

#!/usr/bin/env python

import argparse

# Assuming CalcParser is a subclass of argparse.ArgumentParser
class CalcParser(argparse.ArgumentParser):
    def __init__(self):
        super().__init__(description="Handle calc operations")
        self.add_argument('--input', type=str, help="Input file for calc operation")
        self.add_argument('--output', type=str, help="Output file for calc operation")


if __name__ == "__main__":
    # Top-level parser
    parser = argparse.ArgumentParser(description="Main CLI Application")
    subparsers = parser.add_subparsers(dest="command", required=True)

    # `calc` subcommand using CalcParser
    calc_parser = CalcParser()
    subparsers.add_parser("calc", parents=[calc_parser], add_help=False)

    # `show` subcommand with a clean ArgumentParser
    show_parser = subparsers.add_parser("show", help="Handle show operations")
    show_parser.add_argument('--verbose', action='store_true', help="Enable verbose output")

    # Parse the arguments
    args = parser.parse_args()
    if args.command == "calc":
        print("Executing calc subcommand")
        print(args)
    elif args.command == "show":
        print("Executing show subcommand")
        print(args)

Which seems elegant, but the --help output of it is:

usage: t.py [-h] {calc,show} ...

Main CLI Application

positional arguments:
  {calc,show}
    show       Handle show operations

options:
  -h, --help   show this help message and exit

Which doesn't include the Handle calc operations help line... If on the other hand I don't use add_help=False, I get (naturally):

Traceback (most recent call last):
  File "/home/doron/repos/lab-ion-trap-simulations/./t.py", line 20, in <module>
    subparsers.add_parser("calc", parents=[calc_parser])
  File "/nix/store/px2nj16i5gc3d4mnw5l1nclfdxhry61p-python3-3.12.7/lib/python3.12/argparse.py", line 1231, in add_parser
    parser = self._parser_class(**kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/nix/store/px2nj16i5gc3d4mnw5l1nclfdxhry61p-python3-3.12.7/lib/python3.12/argparse.py", line 1818, in __init__
    self._add_container_actions(parent)
  File "/nix/store/px2nj16i5gc3d4mnw5l1nclfdxhry61p-python3-3.12.7/lib/python3.12/argparse.py", line 1569, in _add_container_actions
    group_map.get(action, self)._add_action(action)
  File "/nix/store/px2nj16i5gc3d4mnw5l1nclfdxhry61p-python3-3.12.7/lib/python3.12/argparse.py", line 1696, in _add_action
    action = super(_ArgumentGroup, self)._add_action(action)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/nix/store/px2nj16i5gc3d4mnw5l1nclfdxhry61p-python3-3.12.7/lib/python3.12/argparse.py", line 1509, in _add_action
    self._check_conflict(action)
  File "/nix/store/px2nj16i5gc3d4mnw5l1nclfdxhry61p-python3-3.12.7/lib/python3.12/argparse.py", line 1645, in _check_conflict
    conflict_handler(action, confl_optionals)
  File "/nix/store/px2nj16i5gc3d4mnw5l1nclfdxhry61p-python3-3.12.7/lib/python3.12/argparse.py", line 1654, in _handle_conflict_error
    raise ArgumentError(action, message % conflict_string)
argparse.ArgumentError: argument -h/--help: conflicting option strings: -h, --help

Which in my opinion concludes that this using the parents argument is not an acceptable resolution to the feature request.