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.