There are several use cases for having the equivalent of the optparse.OptionParser 'get_option' method and the 'option_groups' and 'option_list' properties in argparse.ArgumentParser class.

(1) Easy alteration of the text of the default help option. With optparse, one could write:

>>> oparser.get_option( "-h" ).help
'show this help message and exit'
>>> oparser.get_option( "-h" ).help = "Show this help message and exit."
>>> oparser.get_option( "-h" ).help
'Show this help message and exit.'

The equivalent facility does not appear to exist in argparse. (Issue #19462, http://bugs.python.org/issue19462, is about a different use case. And, while https://docs.python.org/3/library/argparse.html#add-help suggests a workaround with add_help=False and then creating a new option with the 'help' action, it is still less convenient than altering the existing help option.)

(2) Inspection of all the argument declarations in an ArgumentParser object after it has been populated. This is particularly useful if you want to look for the equivalent of the available options in config files and don't want to have write explicit code which separately enumerates the available config file keys and how to handle them. With an OptionParser, one could use the 'option_groups' attribute to find all option groups (to correspond to config file sections) and the 'option_list' attribute to find all options (to correspond to config file keys); these are all part of the published interface and provide relatively simple data types to inspect. With an Argument Parser, one needs to rely upon the unpublished interface (the '_actions' attribute of a parser, etc...).

The attached file subclasses ArgumentParser, explores how these optparse methods might be added to argparse.  The __name__ section demonstrates how they might be used.

argparse differs from optparse in a number of ways:

- all actions are included in the parser._actions list.

- the parser has one dictionary with all option_strings (both short and long)

- argparse also has positionals, which don't have option_strings.  They could be found by 'dest' (or some other attribute), but this does not have to be unique.

- argparse does not use argument groups for parsing; just for formatting the help.

- groups keep a list of their own actions in ._group_actions list.  The ._actions list is shared among the parser and all groups.

- every action is in an argument group, usually one of the 2 default groups.  An action does not have a 'container' attribute.

-------------------

The idea of coordinating config sections with parser argument groups is interesting, but I question whether the stock argparser should be modified to facilitate this.  It sounds like something that belongs in a custom subclass.

Ipython populates its argparse parser with arguments derived from config files.  This provides multiple config levels - default, custom file, and calling arguments.  I don't recall whether it makes any use of argument groups.

@paul.j3, thanks for the sample code for argparse extension. I agree that subclassing is a way to go for use in third-party projects. But, if someone ever wanted to add an abstraction layer in front of argparse.ArgumentParser and configparser.ConfigParser in the standard library, then modification of the argparse module might be more convenient.

However, in the intervening months since I originally filed this ticket, I ended up exploring an alternative to inspecting populated argparse.ArgumentParser instances for this use case (parser abstraction layer). The module I ended up writing is more of a framework in that it lets you supply argument and config parsers and then populate them via a common interface. While this design is perhaps higher maintenance, I think that it gives more flexibility and control than inspecting already-populated parsers. So, from my perspective, I no longer consider this use case to be a compelling reason for adding more optparse-like behavior to argparse.

(If there interest in the little framework that I wrote, I can share my code and take the discussion to an appropriate mailing list.)

Again, thanks for taking the time to write the argparse_extended.py code.

So, this bug report could be closed, right?

Yes, this issue could be closed. I think the concept is still valid and perhaps worthy of future consideration as it is a means of unifying two different configuration processing mechanisms in the standard library without having developers reinvent that wheel every time.

I'll close it, though, if having a "stale" issue floating around is bothersome.