First a note on the argparse
docs - it's basically a how-to-use document, not a formal API. The standard for what argparse
does is the code itself, the unit tests (test/test_argparse.py
), and a paralyzing concern for backward compatibility.
There's no 'official' way of accessing allowed arguments
, because users usually don't need to know that (other than reading the help/usage
).
But let me illustrate with a simple parser in an iteractive session:
In [247]: parser=argparse.ArgumentParser()
In [248]: a = parser.add_argument('pos')
In [249]: b = parser.add_argument('-f','--foo')
add_argument
returns the Action object that it created. This isn't documented, but obvious to any one who has created a parser interactively.
The parser
object has a repr
method, that displays major parameters. But it has many more attributes, which you can see with vars(parser)
, or parser.<tab>
in Ipython.
In [250]: parser
Out[250]: ArgumentParser(prog='ipython3', usage=None, description=None, formatter_class=<class 'argparse.HelpFormatter'>, conflict_handler='error', add_help=True)
The Actions too have repr
; the Action subclass is determined by the action
parameter.
In [251]: a
Out[251]: _StoreAction(option_strings=[], dest='pos', nargs=None, const=None, default=None, type=None, choices=None, help=None, metavar=None)
In [252]: b
Out[252]: _StoreAction(option_strings=['-f', '--foo'], dest='foo', nargs=None, const=None, default=None, type=None, choices=None, help=None, metavar=None)
vars(a)
etc can be used to see all attributes.
A key parser
attribute is _actions
, a list of all defined Actions. This is the basis for all parsing. Note it includes the help
action that was created automatically. Look at option_strings
; that determines whether the Action is positional or optional.
In [253]: parser._actions
Out[253]:
[_HelpAction(option_strings=['-h', '--help'], dest='help', nargs=0, const=None, default='==SUPPRESS==', type=None, choices=None, help='show this help message and exit', metavar=None),
_StoreAction(option_strings=[], dest='pos',....),
_StoreAction(option_strings=['-f', '--foo'], dest='foo', ...)]
_option_string_actions
is a dictionary, mapping from option_strings
to Actions (the same objects that appear in _actions
). References to those Action objects appear all over the place in argparse
code.
In [255]: parser._option_string_actions
Out[255]:
{'--foo': _StoreAction(option_strings=['-f', '--foo'],....),
'--help': _HelpAction(option_strings=['-h', '--help'],...),
'-f': _StoreAction(option_strings=['-f', '--foo'], dest='foo',...),
'-h': _HelpAction(option_strings=['-h', '--help'], ....)}
In [256]: list(parser._option_string_actions.keys())
Out[256]: ['-f', '--help', '-h', '--foo']
Note that there is a key for each -
string, long or short; but there's nothing for pos
, the positional has an empty option_strings
parameter.
If that list of keys is what you want, use it, and don't worry about the _
. It does not have a 'public' alias.
I can understand parsing the help
to discover the same; but that's a lot of work to just avoid using a 'private' attribute. If you worry about the undocumented attribute being changed, you should also worry about the help format being changed. That isn't part of the docs either.
help
layout is controlled by parser.format_help
. The usage
is created from information in self._actions
. Help lines from information in
for action_group in self._action_groups:
formatter.add_arguments(action_group._group_actions)
(you don't want to get into action groups
do you?).
There is another way of getting the option_strings
- collect them from the _actions
:
In [258]: [a.option_strings for a in parser._actions]
Out[258]: [['-h', '--help'], [], ['-f', '--foo']]
===================
Delving in to code details a bit:
parser.add_argument
creates an Action, and then passes it to parser._add_action
. This is the method the populates both .actions
and action.option_strings
.
self._actions.append(action)
for option_string in action.option_strings:
self._option_string_actions[option_string] = action