add remove_argument_group to argparse

[bethard]

BPO	9350
Nosy	@rhettinger, @tirkarthi, @shihai1991, @iritkatriel
Files	remove_argument_group.patch

^{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 = <Date 2021-12-29.22:38:52.420>
created_at = <Date 2010-07-23.13:51:26.899>
labels = ['type-feature', 'library']
title = 'add remove_argument_group to argparse'
updated_at = <Date 2021-12-29.22:38:52.419>
user = 'https://bugs.python.org/bethard'

bugs.python.org fields:

activity = <Date 2021-12-29.22:38:52.419>
actor = 'iritkatriel'
assignee = 'none'
closed = True
closed_date = <Date 2021-12-29.22:38:52.420>
closer = 'iritkatriel'
components = ['Library (Lib)']
creation = <Date 2010-07-23.13:51:26.899>
creator = 'bethard'
dependencies = []
files = ['29489']
hgrepos = []
issue_num = 9350
keywords = ['patch']
message_count = 8.0
messages = ['111321', '221730', '227779', '349920', '349921', '349929', '349932', '408542']
nosy_count = 7.0
nosy_names = ['rhettinger', 'bethard', 'paul.j3', 'Sanjeev', 'xtreak', 'shihai1991', 'iritkatriel']
pr_nums = []
priority = 'normal'
resolution = 'rejected'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue9350'
versions = ['Python 2.7', 'Python 3.5']

[bethard]

[From http://code.google.com/p/argparse/issues/detail?id=71]

There is a method ArgumentParser.add_argument_group() to create and add an argument group to the parser. I would like the ability to remove an argument group via a method like remove_argument_group(group).

The use case for me is I create an argument group and then conditionally add a bunch of arguments to it. If zero arguments are added I would like to then remove the group so that an empty group does not show up in the help output.

[paulj3]

I wonder if this patch is needed.

• there hasn't been discussion in 4 years

• In Steven's use case, a group without any arguments, the group does not show up. A common example of an empty argument group, is a parser without any user defined arguments.

    p=argparse.ArgumentParser(prog='PROG')
    p.print_help()

usage: PROG [-h]
optional arguments:
  -h, --help  show this help message and exit

The empty 'positional arguments' group is not displayed.

Removing a group that has arguments is more complicated (and error prone) since it requires removing those arguments as well. There is a '_remove_action' method. But as best I can tell it is only used by '_handle_conflict_resolve', a rarely used alternative conflict handler.

[paulj3]

If the empty argument group has a 'description' it is displayed. For example with positionals group that I mentioned earlier:

     parser = argparse.ArgumentParser()
     parser._action_groups[0].description = 'test'
     parser.print_help()

produces

usage: ipython [-h]

positional arguments:
  test

optional arguments:
   -h, --help  show this help message and exit

So the user can fix this empty group display issue by setting this 'description' value to None.

[shihai1991]

IMHO, if we supply the ability to add an argument group, we need add the ability to remove the argument group too.

[paulj3]

hai shi

Do you have a specific need for this, or do you want it just for the same of completeness?

[rhettinger]

The use case for me is I create an argument group and
then conditionally add a bunch of arguments to it.
If zero arguments are added I would like to then remove
the group so that an empty group does not show up
in the help output.

ISTM this use is likely rare enough that it doesn't warrant an API expansion. The argparse API is already somewhat large, so we should only expand it when there is a compelling benefit or the absence of a reasonable workaround (i.e. lazily adding a group only when the first argument is added).

[shihai1991]

paul, raymond. Thanks for give me a quick answer:).
Looks raymond's reason is good enough, i just only consider this question from
api completeness(as paul said) not from user case.

[iritkatriel]

This is over a decade old and the discussion is mostly that it's not worth doing, so I suggest we close.