Home | History | Annotate | Download | only in library
      1 :mod:`argparse` --- Parser for command-line options, arguments and sub-commands
      2 ===============================================================================
      3 
      4 .. module:: argparse
      5    :synopsis: Command-line option and argument parsing library.
      6 .. moduleauthor:: Steven Bethard <steven.bethard (a] gmail.com>
      7 .. sectionauthor:: Steven Bethard <steven.bethard (a] gmail.com>
      8 
      9 .. versionadded:: 2.7
     10 
     11 **Source code:** :source:`Lib/argparse.py`
     12 
     13 --------------
     14 
     15 .. sidebar:: Tutorial
     16 
     17    This page contains the API reference information. For a more gentle
     18    introduction to Python command-line parsing, have a look at the
     19    :ref:`argparse tutorial <argparse-tutorial>`.
     20 
     21 The :mod:`argparse` module makes it easy to write user-friendly command-line
     22 interfaces. The program defines what arguments it requires, and :mod:`argparse`
     23 will figure out how to parse those out of :data:`sys.argv`.  The :mod:`argparse`
     24 module also automatically generates help and usage messages and issues errors
     25 when users give the program invalid arguments.
     26 
     27 
     28 Example
     29 -------
     30 
     31 The following code is a Python program that takes a list of integers and
     32 produces either the sum or the max::
     33 
     34    import argparse
     35 
     36    parser = argparse.ArgumentParser(description='Process some integers.')
     37    parser.add_argument('integers', metavar='N', type=int, nargs='+',
     38                        help='an integer for the accumulator')
     39    parser.add_argument('--sum', dest='accumulate', action='store_const',
     40                        const=sum, default=max,
     41                        help='sum the integers (default: find the max)')
     42 
     43    args = parser.parse_args()
     44    print args.accumulate(args.integers)
     45 
     46 Assuming the Python code above is saved into a file called ``prog.py``, it can
     47 be run at the command line and provides useful help messages:
     48 
     49 .. code-block:: shell-session
     50 
     51    $ python prog.py -h
     52    usage: prog.py [-h] [--sum] N [N ...]
     53 
     54    Process some integers.
     55 
     56    positional arguments:
     57     N           an integer for the accumulator
     58 
     59    optional arguments:
     60     -h, --help  show this help message and exit
     61     --sum       sum the integers (default: find the max)
     62 
     63 When run with the appropriate arguments, it prints either the sum or the max of
     64 the command-line integers:
     65 
     66 .. code-block:: shell-session
     67 
     68    $ python prog.py 1 2 3 4
     69    4
     70 
     71    $ python prog.py 1 2 3 4 --sum
     72    10
     73 
     74 If invalid arguments are passed in, it will issue an error:
     75 
     76 .. code-block:: shell-session
     77 
     78    $ python prog.py a b c
     79    usage: prog.py [-h] [--sum] N [N ...]
     80    prog.py: error: argument N: invalid int value: 'a'
     81 
     82 The following sections walk you through this example.
     83 
     84 
     85 Creating a parser
     86 ^^^^^^^^^^^^^^^^^
     87 
     88 The first step in using the :mod:`argparse` is creating an
     89 :class:`ArgumentParser` object::
     90 
     91    >>> parser = argparse.ArgumentParser(description='Process some integers.')
     92 
     93 The :class:`ArgumentParser` object will hold all the information necessary to
     94 parse the command line into Python data types.
     95 
     96 
     97 Adding arguments
     98 ^^^^^^^^^^^^^^^^
     99 
    100 Filling an :class:`ArgumentParser` with information about program arguments is
    101 done by making calls to the :meth:`~ArgumentParser.add_argument` method.
    102 Generally, these calls tell the :class:`ArgumentParser` how to take the strings
    103 on the command line and turn them into objects.  This information is stored and
    104 used when :meth:`~ArgumentParser.parse_args` is called. For example::
    105 
    106    >>> parser.add_argument('integers', metavar='N', type=int, nargs='+',
    107    ...                     help='an integer for the accumulator')
    108    >>> parser.add_argument('--sum', dest='accumulate', action='store_const',
    109    ...                     const=sum, default=max,
    110    ...                     help='sum the integers (default: find the max)')
    111 
    112 Later, calling :meth:`~ArgumentParser.parse_args` will return an object with
    113 two attributes, ``integers`` and ``accumulate``.  The ``integers`` attribute
    114 will be a list of one or more ints, and the ``accumulate`` attribute will be
    115 either the :func:`sum` function, if ``--sum`` was specified at the command line,
    116 or the :func:`max` function if it was not.
    117 
    118 
    119 Parsing arguments
    120 ^^^^^^^^^^^^^^^^^
    121 
    122 :class:`ArgumentParser` parses arguments through the
    123 :meth:`~ArgumentParser.parse_args` method.  This will inspect the command line,
    124 convert each argument to the appropriate type and then invoke the appropriate action.
    125 In most cases, this means a simple :class:`Namespace` object will be built up from
    126 attributes parsed out of the command line::
    127 
    128    >>> parser.parse_args(['--sum', '7', '-1', '42'])
    129    Namespace(accumulate=<built-in function sum>, integers=[7, -1, 42])
    130 
    131 In a script, :meth:`~ArgumentParser.parse_args` will typically be called with no
    132 arguments, and the :class:`ArgumentParser` will automatically determine the
    133 command-line arguments from :data:`sys.argv`.
    134 
    135 
    136 ArgumentParser objects
    137 ----------------------
    138 
    139 .. class:: ArgumentParser(prog=None, usage=None, description=None, \
    140                           epilog=None, parents=[], \
    141                           formatter_class=argparse.HelpFormatter, \
    142                           prefix_chars='-', fromfile_prefix_chars=None, \
    143                           argument_default=None, conflict_handler='error', \
    144                           add_help=True)
    145 
    146    Create a new :class:`ArgumentParser` object. All parameters should be passed
    147    as keyword arguments. Each parameter has its own more detailed description
    148    below, but in short they are:
    149 
    150    * prog_ - The name of the program (default: ``sys.argv[0]``)
    151 
    152    * usage_ - The string describing the program usage (default: generated from
    153      arguments added to parser)
    154 
    155    * description_ - Text to display before the argument help (default: none)
    156 
    157    * epilog_ - Text to display after the argument help (default: none)
    158 
    159    * parents_ - A list of :class:`ArgumentParser` objects whose arguments should
    160      also be included
    161 
    162    * formatter_class_ - A class for customizing the help output
    163 
    164    * prefix_chars_ - The set of characters that prefix optional arguments
    165      (default: '-')
    166 
    167    * fromfile_prefix_chars_ - The set of characters that prefix files from
    168      which additional arguments should be read (default: ``None``)
    169 
    170    * argument_default_ - The global default value for arguments
    171      (default: ``None``)
    172 
    173    * conflict_handler_ - The strategy for resolving conflicting optionals
    174      (usually unnecessary)
    175 
    176    * add_help_ - Add a -h/--help option to the parser (default: ``True``)
    177 
    178 The following sections describe how each of these are used.
    179 
    180 
    181 prog
    182 ^^^^
    183 
    184 By default, :class:`ArgumentParser` objects use ``sys.argv[0]`` to determine
    185 how to display the name of the program in help messages.  This default is almost
    186 always desirable because it will make the help messages match how the program was
    187 invoked on the command line.  For example, consider a file named
    188 ``myprogram.py`` with the following code::
    189 
    190    import argparse
    191    parser = argparse.ArgumentParser()
    192    parser.add_argument('--foo', help='foo help')
    193    args = parser.parse_args()
    194 
    195 The help for this program will display ``myprogram.py`` as the program name
    196 (regardless of where the program was invoked from):
    197 
    198 .. code-block:: shell-session
    199 
    200    $ python myprogram.py --help
    201    usage: myprogram.py [-h] [--foo FOO]
    202 
    203    optional arguments:
    204     -h, --help  show this help message and exit
    205     --foo FOO   foo help
    206    $ cd ..
    207    $ python subdir\myprogram.py --help
    208    usage: myprogram.py [-h] [--foo FOO]
    209 
    210    optional arguments:
    211     -h, --help  show this help message and exit
    212     --foo FOO   foo help
    213 
    214 To change this default behavior, another value can be supplied using the
    215 ``prog=`` argument to :class:`ArgumentParser`::
    216 
    217    >>> parser = argparse.ArgumentParser(prog='myprogram')
    218    >>> parser.print_help()
    219    usage: myprogram [-h]
    220 
    221    optional arguments:
    222     -h, --help  show this help message and exit
    223 
    224 Note that the program name, whether determined from ``sys.argv[0]`` or from the
    225 ``prog=`` argument, is available to help messages using the ``%(prog)s`` format
    226 specifier.
    227 
    228 ::
    229 
    230    >>> parser = argparse.ArgumentParser(prog='myprogram')
    231    >>> parser.add_argument('--foo', help='foo of the %(prog)s program')
    232    >>> parser.print_help()
    233    usage: myprogram [-h] [--foo FOO]
    234 
    235    optional arguments:
    236     -h, --help  show this help message and exit
    237     --foo FOO   foo of the myprogram program
    238 
    239 
    240 usage
    241 ^^^^^
    242 
    243 By default, :class:`ArgumentParser` calculates the usage message from the
    244 arguments it contains::
    245 
    246    >>> parser = argparse.ArgumentParser(prog='PROG')
    247    >>> parser.add_argument('--foo', nargs='?', help='foo help')
    248    >>> parser.add_argument('bar', nargs='+', help='bar help')
    249    >>> parser.print_help()
    250    usage: PROG [-h] [--foo [FOO]] bar [bar ...]
    251 
    252    positional arguments:
    253     bar          bar help
    254 
    255    optional arguments:
    256     -h, --help   show this help message and exit
    257     --foo [FOO]  foo help
    258 
    259 The default message can be overridden with the ``usage=`` keyword argument::
    260 
    261    >>> parser = argparse.ArgumentParser(prog='PROG', usage='%(prog)s [options]')
    262    >>> parser.add_argument('--foo', nargs='?', help='foo help')
    263    >>> parser.add_argument('bar', nargs='+', help='bar help')
    264    >>> parser.print_help()
    265    usage: PROG [options]
    266 
    267    positional arguments:
    268     bar          bar help
    269 
    270    optional arguments:
    271     -h, --help   show this help message and exit
    272     --foo [FOO]  foo help
    273 
    274 The ``%(prog)s`` format specifier is available to fill in the program name in
    275 your usage messages.
    276 
    277 
    278 description
    279 ^^^^^^^^^^^
    280 
    281 Most calls to the :class:`ArgumentParser` constructor will use the
    282 ``description=`` keyword argument.  This argument gives a brief description of
    283 what the program does and how it works.  In help messages, the description is
    284 displayed between the command-line usage string and the help messages for the
    285 various arguments::
    286 
    287    >>> parser = argparse.ArgumentParser(description='A foo that bars')
    288    >>> parser.print_help()
    289    usage: argparse.py [-h]
    290 
    291    A foo that bars
    292 
    293    optional arguments:
    294     -h, --help  show this help message and exit
    295 
    296 By default, the description will be line-wrapped so that it fits within the
    297 given space.  To change this behavior, see the formatter_class_ argument.
    298 
    299 
    300 epilog
    301 ^^^^^^
    302 
    303 Some programs like to display additional description of the program after the
    304 description of the arguments.  Such text can be specified using the ``epilog=``
    305 argument to :class:`ArgumentParser`::
    306 
    307    >>> parser = argparse.ArgumentParser(
    308    ...     description='A foo that bars',
    309    ...     epilog="And that's how you'd foo a bar")
    310    >>> parser.print_help()
    311    usage: argparse.py [-h]
    312 
    313    A foo that bars
    314 
    315    optional arguments:
    316     -h, --help  show this help message and exit
    317 
    318    And that's how you'd foo a bar
    319 
    320 As with the description_ argument, the ``epilog=`` text is by default
    321 line-wrapped, but this behavior can be adjusted with the formatter_class_
    322 argument to :class:`ArgumentParser`.
    323 
    324 
    325 parents
    326 ^^^^^^^
    327 
    328 Sometimes, several parsers share a common set of arguments. Rather than
    329 repeating the definitions of these arguments, a single parser with all the
    330 shared arguments and passed to ``parents=`` argument to :class:`ArgumentParser`
    331 can be used.  The ``parents=`` argument takes a list of :class:`ArgumentParser`
    332 objects, collects all the positional and optional actions from them, and adds
    333 these actions to the :class:`ArgumentParser` object being constructed::
    334 
    335    >>> parent_parser = argparse.ArgumentParser(add_help=False)
    336    >>> parent_parser.add_argument('--parent', type=int)
    337 
    338    >>> foo_parser = argparse.ArgumentParser(parents=[parent_parser])
    339    >>> foo_parser.add_argument('foo')
    340    >>> foo_parser.parse_args(['--parent', '2', 'XXX'])
    341    Namespace(foo='XXX', parent=2)
    342 
    343    >>> bar_parser = argparse.ArgumentParser(parents=[parent_parser])
    344    >>> bar_parser.add_argument('--bar')
    345    >>> bar_parser.parse_args(['--bar', 'YYY'])
    346    Namespace(bar='YYY', parent=None)
    347 
    348 Note that most parent parsers will specify ``add_help=False``.  Otherwise, the
    349 :class:`ArgumentParser` will see two ``-h/--help`` options (one in the parent
    350 and one in the child) and raise an error.
    351 
    352 .. note::
    353    You must fully initialize the parsers before passing them via ``parents=``.
    354    If you change the parent parsers after the child parser, those changes will
    355    not be reflected in the child.
    356 
    357 
    358 formatter_class
    359 ^^^^^^^^^^^^^^^
    360 
    361 :class:`ArgumentParser` objects allow the help formatting to be customized by
    362 specifying an alternate formatting class.  Currently, there are three such
    363 classes:
    364 
    365 .. class:: RawDescriptionHelpFormatter
    366            RawTextHelpFormatter
    367            ArgumentDefaultsHelpFormatter
    368 
    369 The first two allow more control over how textual descriptions are displayed,
    370 while the last automatically adds information about argument default values.
    371 
    372 By default, :class:`ArgumentParser` objects line-wrap the description_ and
    373 epilog_ texts in command-line help messages::
    374 
    375    >>> parser = argparse.ArgumentParser(
    376    ...     prog='PROG',
    377    ...     description='''this description
    378    ...         was indented weird
    379    ...             but that is okay''',
    380    ...     epilog='''
    381    ...             likewise for this epilog whose whitespace will
    382    ...         be cleaned up and whose words will be wrapped
    383    ...         across a couple lines''')
    384    >>> parser.print_help()
    385    usage: PROG [-h]
    386 
    387    this description was indented weird but that is okay
    388 
    389    optional arguments:
    390     -h, --help  show this help message and exit
    391 
    392    likewise for this epilog whose whitespace will be cleaned up and whose words
    393    will be wrapped across a couple lines
    394 
    395 Passing :class:`RawDescriptionHelpFormatter` as ``formatter_class=``
    396 indicates that description_ and epilog_ are already correctly formatted and
    397 should not be line-wrapped::
    398 
    399    >>> parser = argparse.ArgumentParser(
    400    ...     prog='PROG',
    401    ...     formatter_class=argparse.RawDescriptionHelpFormatter,
    402    ...     description=textwrap.dedent('''\
    403    ...         Please do not mess up this text!
    404    ...         --------------------------------
    405    ...             I have indented it
    406    ...             exactly the way
    407    ...             I want it
    408    ...         '''))
    409    >>> parser.print_help()
    410    usage: PROG [-h]
    411 
    412    Please do not mess up this text!
    413    --------------------------------
    414       I have indented it
    415       exactly the way
    416       I want it
    417 
    418    optional arguments:
    419     -h, --help  show this help message and exit
    420 
    421 :class:`RawTextHelpFormatter` maintains whitespace for all sorts of help text,
    422 including argument descriptions.
    423 
    424 The other formatter class available, :class:`ArgumentDefaultsHelpFormatter`,
    425 will add information about the default value of each of the arguments::
    426 
    427    >>> parser = argparse.ArgumentParser(
    428    ...     prog='PROG',
    429    ...     formatter_class=argparse.ArgumentDefaultsHelpFormatter)
    430    >>> parser.add_argument('--foo', type=int, default=42, help='FOO!')
    431    >>> parser.add_argument('bar', nargs='*', default=[1, 2, 3], help='BAR!')
    432    >>> parser.print_help()
    433    usage: PROG [-h] [--foo FOO] [bar [bar ...]]
    434 
    435    positional arguments:
    436     bar         BAR! (default: [1, 2, 3])
    437 
    438    optional arguments:
    439     -h, --help  show this help message and exit
    440     --foo FOO   FOO! (default: 42)
    441 
    442 
    443 prefix_chars
    444 ^^^^^^^^^^^^
    445 
    446 Most command-line options will use ``-`` as the prefix, e.g. ``-f/--foo``.
    447 Parsers that need to support different or additional prefix
    448 characters, e.g. for options
    449 like ``+f`` or ``/foo``, may specify them using the ``prefix_chars=`` argument
    450 to the ArgumentParser constructor::
    451 
    452    >>> parser = argparse.ArgumentParser(prog='PROG', prefix_chars='-+')
    453    >>> parser.add_argument('+f')
    454    >>> parser.add_argument('++bar')
    455    >>> parser.parse_args('+f X ++bar Y'.split())
    456    Namespace(bar='Y', f='X')
    457 
    458 The ``prefix_chars=`` argument defaults to ``'-'``. Supplying a set of
    459 characters that does not include ``-`` will cause ``-f/--foo`` options to be
    460 disallowed.
    461 
    462 
    463 fromfile_prefix_chars
    464 ^^^^^^^^^^^^^^^^^^^^^
    465 
    466 Sometimes, for example when dealing with a particularly long argument lists, it
    467 may make sense to keep the list of arguments in a file rather than typing it out
    468 at the command line.  If the ``fromfile_prefix_chars=`` argument is given to the
    469 :class:`ArgumentParser` constructor, then arguments that start with any of the
    470 specified characters will be treated as files, and will be replaced by the
    471 arguments they contain.  For example::
    472 
    473    >>> with open('args.txt', 'w') as fp:
    474    ...     fp.write('-f\nbar')
    475    >>> parser = argparse.ArgumentParser(fromfile_prefix_chars='@')
    476    >>> parser.add_argument('-f')
    477    >>> parser.parse_args(['-f', 'foo', '@args.txt'])
    478    Namespace(f='bar')
    479 
    480 Arguments read from a file must by default be one per line (but see also
    481 :meth:`~ArgumentParser.convert_arg_line_to_args`) and are treated as if they
    482 were in the same place as the original file referencing argument on the command
    483 line.  So in the example above, the expression ``['-f', 'foo', '@args.txt']``
    484 is considered equivalent to the expression ``['-f', 'foo', '-f', 'bar']``.
    485 
    486 The ``fromfile_prefix_chars=`` argument defaults to ``None``, meaning that
    487 arguments will never be treated as file references.
    488 
    489 
    490 argument_default
    491 ^^^^^^^^^^^^^^^^
    492 
    493 Generally, argument defaults are specified either by passing a default to
    494 :meth:`~ArgumentParser.add_argument` or by calling the
    495 :meth:`~ArgumentParser.set_defaults` methods with a specific set of name-value
    496 pairs.  Sometimes however, it may be useful to specify a single parser-wide
    497 default for arguments.  This can be accomplished by passing the
    498 ``argument_default=`` keyword argument to :class:`ArgumentParser`.  For example,
    499 to globally suppress attribute creation on :meth:`~ArgumentParser.parse_args`
    500 calls, we supply ``argument_default=SUPPRESS``::
    501 
    502    >>> parser = argparse.ArgumentParser(argument_default=argparse.SUPPRESS)
    503    >>> parser.add_argument('--foo')
    504    >>> parser.add_argument('bar', nargs='?')
    505    >>> parser.parse_args(['--foo', '1', 'BAR'])
    506    Namespace(bar='BAR', foo='1')
    507    >>> parser.parse_args([])
    508    Namespace()
    509 
    510 
    511 conflict_handler
    512 ^^^^^^^^^^^^^^^^
    513 
    514 :class:`ArgumentParser` objects do not allow two actions with the same option
    515 string.  By default, :class:`ArgumentParser` objects raise an exception if an
    516 attempt is made to create an argument with an option string that is already in
    517 use::
    518 
    519    >>> parser = argparse.ArgumentParser(prog='PROG')
    520    >>> parser.add_argument('-f', '--foo', help='old foo help')
    521    >>> parser.add_argument('--foo', help='new foo help')
    522    Traceback (most recent call last):
    523     ..
    524    ArgumentError: argument --foo: conflicting option string(s): --foo
    525 
    526 Sometimes (e.g. when using parents_) it may be useful to simply override any
    527 older arguments with the same option string.  To get this behavior, the value
    528 ``'resolve'`` can be supplied to the ``conflict_handler=`` argument of
    529 :class:`ArgumentParser`::
    530 
    531    >>> parser = argparse.ArgumentParser(prog='PROG', conflict_handler='resolve')
    532    >>> parser.add_argument('-f', '--foo', help='old foo help')
    533    >>> parser.add_argument('--foo', help='new foo help')
    534    >>> parser.print_help()
    535    usage: PROG [-h] [-f FOO] [--foo FOO]
    536 
    537    optional arguments:
    538     -h, --help  show this help message and exit
    539     -f FOO      old foo help
    540     --foo FOO   new foo help
    541 
    542 Note that :class:`ArgumentParser` objects only remove an action if all of its
    543 option strings are overridden.  So, in the example above, the old ``-f/--foo``
    544 action is retained as the ``-f`` action, because only the ``--foo`` option
    545 string was overridden.
    546 
    547 
    548 add_help
    549 ^^^^^^^^
    550 
    551 By default, ArgumentParser objects add an option which simply displays
    552 the parser's help message. For example, consider a file named
    553 ``myprogram.py`` containing the following code::
    554 
    555    import argparse
    556    parser = argparse.ArgumentParser()
    557    parser.add_argument('--foo', help='foo help')
    558    args = parser.parse_args()
    559 
    560 If ``-h`` or ``--help`` is supplied at the command line, the ArgumentParser
    561 help will be printed:
    562 
    563 .. code-block:: shell-session
    564 
    565    $ python myprogram.py --help
    566    usage: myprogram.py [-h] [--foo FOO]
    567 
    568    optional arguments:
    569     -h, --help  show this help message and exit
    570     --foo FOO   foo help
    571 
    572 Occasionally, it may be useful to disable the addition of this help option.
    573 This can be achieved by passing ``False`` as the ``add_help=`` argument to
    574 :class:`ArgumentParser`::
    575 
    576    >>> parser = argparse.ArgumentParser(prog='PROG', add_help=False)
    577    >>> parser.add_argument('--foo', help='foo help')
    578    >>> parser.print_help()
    579    usage: PROG [--foo FOO]
    580 
    581    optional arguments:
    582     --foo FOO  foo help
    583 
    584 The help option is typically ``-h/--help``. The exception to this is
    585 if the ``prefix_chars=`` is specified and does not include ``-``, in
    586 which case ``-h`` and ``--help`` are not valid options.  In
    587 this case, the first character in ``prefix_chars`` is used to prefix
    588 the help options::
    589 
    590    >>> parser = argparse.ArgumentParser(prog='PROG', prefix_chars='+/')
    591    >>> parser.print_help()
    592    usage: PROG [+h]
    593 
    594    optional arguments:
    595      +h, ++help  show this help message and exit
    596 
    597 
    598 The add_argument() method
    599 -------------------------
    600 
    601 .. method:: ArgumentParser.add_argument(name or flags..., [action], [nargs], \
    602                            [const], [default], [type], [choices], [required], \
    603                            [help], [metavar], [dest])
    604 
    605    Define how a single command-line argument should be parsed.  Each parameter
    606    has its own more detailed description below, but in short they are:
    607 
    608    * `name or flags`_ - Either a name or a list of option strings, e.g. ``foo``
    609      or ``-f, --foo``.
    610 
    611    * action_ - The basic type of action to be taken when this argument is
    612      encountered at the command line.
    613 
    614    * nargs_ - The number of command-line arguments that should be consumed.
    615 
    616    * const_ - A constant value required by some action_ and nargs_ selections.
    617 
    618    * default_ - The value produced if the argument is absent from the
    619      command line.
    620 
    621    * type_ - The type to which the command-line argument should be converted.
    622 
    623    * choices_ - A container of the allowable values for the argument.
    624 
    625    * required_ - Whether or not the command-line option may be omitted
    626      (optionals only).
    627 
    628    * help_ - A brief description of what the argument does.
    629 
    630    * metavar_ - A name for the argument in usage messages.
    631 
    632    * dest_ - The name of the attribute to be added to the object returned by
    633      :meth:`parse_args`.
    634 
    635 The following sections describe how each of these are used.
    636 
    637 
    638 name or flags
    639 ^^^^^^^^^^^^^
    640 
    641 The :meth:`~ArgumentParser.add_argument` method must know whether an optional
    642 argument, like ``-f`` or ``--foo``, or a positional argument, like a list of
    643 filenames, is expected.  The first arguments passed to
    644 :meth:`~ArgumentParser.add_argument` must therefore be either a series of
    645 flags, or a simple argument name.  For example, an optional argument could
    646 be created like::
    647 
    648    >>> parser.add_argument('-f', '--foo')
    649 
    650 while a positional argument could be created like::
    651 
    652    >>> parser.add_argument('bar')
    653 
    654 When :meth:`~ArgumentParser.parse_args` is called, optional arguments will be
    655 identified by the ``-`` prefix, and the remaining arguments will be assumed to
    656 be positional::
    657 
    658    >>> parser = argparse.ArgumentParser(prog='PROG')
    659    >>> parser.add_argument('-f', '--foo')
    660    >>> parser.add_argument('bar')
    661    >>> parser.parse_args(['BAR'])
    662    Namespace(bar='BAR', foo=None)
    663    >>> parser.parse_args(['BAR', '--foo', 'FOO'])
    664    Namespace(bar='BAR', foo='FOO')
    665    >>> parser.parse_args(['--foo', 'FOO'])
    666    usage: PROG [-h] [-f FOO] bar
    667    PROG: error: too few arguments
    668 
    669 
    670 action
    671 ^^^^^^
    672 
    673 :class:`ArgumentParser` objects associate command-line arguments with actions.  These
    674 actions can do just about anything with the command-line arguments associated with
    675 them, though most actions simply add an attribute to the object returned by
    676 :meth:`~ArgumentParser.parse_args`.  The ``action`` keyword argument specifies
    677 how the command-line arguments should be handled. The supplied actions are:
    678 
    679 * ``'store'`` - This just stores the argument's value.  This is the default
    680   action. For example::
    681 
    682     >>> parser = argparse.ArgumentParser()
    683     >>> parser.add_argument('--foo')
    684     >>> parser.parse_args('--foo 1'.split())
    685     Namespace(foo='1')
    686 
    687 * ``'store_const'`` - This stores the value specified by the const_ keyword
    688   argument.  The ``'store_const'`` action is most commonly used with
    689   optional arguments that specify some sort of flag.  For example::
    690 
    691     >>> parser = argparse.ArgumentParser()
    692     >>> parser.add_argument('--foo', action='store_const', const=42)
    693     >>> parser.parse_args(['--foo'])
    694     Namespace(foo=42)
    695 
    696 * ``'store_true'`` and ``'store_false'`` - These are special cases of
    697   ``'store_const'`` using for storing the values ``True`` and ``False``
    698   respectively.  In addition, they create default values of ``False`` and ``True``
    699   respectively.  For example::
    700 
    701     >>> parser = argparse.ArgumentParser()
    702     >>> parser.add_argument('--foo', action='store_true')
    703     >>> parser.add_argument('--bar', action='store_false')
    704     >>> parser.add_argument('--baz', action='store_false')
    705     >>> parser.parse_args('--foo --bar'.split())
    706     Namespace(bar=False, baz=True, foo=True)
    707 
    708 * ``'append'`` - This stores a list, and appends each argument value to the
    709   list.  This is useful to allow an option to be specified multiple times.
    710   Example usage::
    711 
    712     >>> parser = argparse.ArgumentParser()
    713     >>> parser.add_argument('--foo', action='append')
    714     >>> parser.parse_args('--foo 1 --foo 2'.split())
    715     Namespace(foo=['1', '2'])
    716 
    717 * ``'append_const'`` - This stores a list, and appends the value specified by
    718   the const_ keyword argument to the list.  (Note that the const_ keyword
    719   argument defaults to ``None``.)  The ``'append_const'`` action is typically
    720   useful when multiple arguments need to store constants to the same list. For
    721   example::
    722 
    723     >>> parser = argparse.ArgumentParser()
    724     >>> parser.add_argument('--str', dest='types', action='append_const', const=str)
    725     >>> parser.add_argument('--int', dest='types', action='append_const', const=int)
    726     >>> parser.parse_args('--str --int'.split())
    727     Namespace(types=[<type 'str'>, <type 'int'>])
    728 
    729 * ``'count'`` - This counts the number of times a keyword argument occurs. For
    730   example, this is useful for increasing verbosity levels::
    731 
    732     >>> parser = argparse.ArgumentParser()
    733     >>> parser.add_argument('--verbose', '-v', action='count')
    734     >>> parser.parse_args(['-vvv'])
    735     Namespace(verbose=3)
    736 
    737 * ``'help'`` - This prints a complete help message for all the options in the
    738   current parser and then exits. By default a help action is automatically
    739   added to the parser. See :class:`ArgumentParser` for details of how the
    740   output is created.
    741 
    742 * ``'version'`` - This expects a ``version=`` keyword argument in the
    743   :meth:`~ArgumentParser.add_argument` call, and prints version information
    744   and exits when invoked::
    745 
    746     >>> import argparse
    747     >>> parser = argparse.ArgumentParser(prog='PROG')
    748     >>> parser.add_argument('--version', action='version', version='%(prog)s 2.0')
    749     >>> parser.parse_args(['--version'])
    750     PROG 2.0
    751 
    752 You may also specify an arbitrary action by passing an Action subclass or
    753 other object that implements the same interface.  The recommended way to do
    754 this is to extend :class:`Action`, overriding the ``__call__`` method
    755 and optionally the ``__init__`` method.
    756 
    757 An example of a custom action::
    758 
    759    >>> class FooAction(argparse.Action):
    760    ...     def __init__(self, option_strings, dest, nargs=None, **kwargs):
    761    ...         if nargs is not None:
    762    ...             raise ValueError("nargs not allowed")
    763    ...         super(FooAction, self).__init__(option_strings, dest, **kwargs)
    764    ...     def __call__(self, parser, namespace, values, option_string=None):
    765    ...         print '%r %r %r' % (namespace, values, option_string)
    766    ...         setattr(namespace, self.dest, values)
    767    ...
    768    >>> parser = argparse.ArgumentParser()
    769    >>> parser.add_argument('--foo', action=FooAction)
    770    >>> parser.add_argument('bar', action=FooAction)
    771    >>> args = parser.parse_args('1 --foo 2'.split())
    772    Namespace(bar=None, foo=None) '1' None
    773    Namespace(bar='1', foo=None) '2' '--foo'
    774    >>> args
    775    Namespace(bar='1', foo='2')
    776 
    777 For more details, see :class:`Action`.
    778 
    779 nargs
    780 ^^^^^
    781 
    782 ArgumentParser objects usually associate a single command-line argument with a
    783 single action to be taken.  The ``nargs`` keyword argument associates a
    784 different number of command-line arguments with a single action.  The supported
    785 values are:
    786 
    787 * ``N`` (an integer).  ``N`` arguments from the command line will be gathered
    788   together into a list.  For example::
    789 
    790      >>> parser = argparse.ArgumentParser()
    791      >>> parser.add_argument('--foo', nargs=2)
    792      >>> parser.add_argument('bar', nargs=1)
    793      >>> parser.parse_args('c --foo a b'.split())
    794      Namespace(bar=['c'], foo=['a', 'b'])
    795 
    796   Note that ``nargs=1`` produces a list of one item.  This is different from
    797   the default, in which the item is produced by itself.
    798 
    799 * ``'?'``. One argument will be consumed from the command line if possible, and
    800   produced as a single item.  If no command-line argument is present, the value from
    801   default_ will be produced.  Note that for optional arguments, there is an
    802   additional case - the option string is present but not followed by a
    803   command-line argument.  In this case the value from const_ will be produced.  Some
    804   examples to illustrate this::
    805 
    806      >>> parser = argparse.ArgumentParser()
    807      >>> parser.add_argument('--foo', nargs='?', const='c', default='d')
    808      >>> parser.add_argument('bar', nargs='?', default='d')
    809      >>> parser.parse_args(['XX', '--foo', 'YY'])
    810      Namespace(bar='XX', foo='YY')
    811      >>> parser.parse_args(['XX', '--foo'])
    812      Namespace(bar='XX', foo='c')
    813      >>> parser.parse_args([])
    814      Namespace(bar='d', foo='d')
    815 
    816   One of the more common uses of ``nargs='?'`` is to allow optional input and
    817   output files::
    818 
    819      >>> parser = argparse.ArgumentParser()
    820      >>> parser.add_argument('infile', nargs='?', type=argparse.FileType('r'),
    821      ...                     default=sys.stdin)
    822      >>> parser.add_argument('outfile', nargs='?', type=argparse.FileType('w'),
    823      ...                     default=sys.stdout)
    824      >>> parser.parse_args(['input.txt', 'output.txt'])
    825      Namespace(infile=<open file 'input.txt', mode 'r' at 0x...>,
    826                outfile=<open file 'output.txt', mode 'w' at 0x...>)
    827      >>> parser.parse_args([])
    828      Namespace(infile=<open file '<stdin>', mode 'r' at 0x...>,
    829                outfile=<open file '<stdout>', mode 'w' at 0x...>)
    830 
    831 * ``'*'``.  All command-line arguments present are gathered into a list.  Note that
    832   it generally doesn't make much sense to have more than one positional argument
    833   with ``nargs='*'``, but multiple optional arguments with ``nargs='*'`` is
    834   possible.  For example::
    835 
    836      >>> parser = argparse.ArgumentParser()
    837      >>> parser.add_argument('--foo', nargs='*')
    838      >>> parser.add_argument('--bar', nargs='*')
    839      >>> parser.add_argument('baz', nargs='*')
    840      >>> parser.parse_args('a b --foo x y --bar 1 2'.split())
    841      Namespace(bar=['1', '2'], baz=['a', 'b'], foo=['x', 'y'])
    842 
    843 * ``'+'``. Just like ``'*'``, all command-line args present are gathered into a
    844   list.  Additionally, an error message will be generated if there wasn't at
    845   least one command-line argument present.  For example::
    846 
    847      >>> parser = argparse.ArgumentParser(prog='PROG')
    848      >>> parser.add_argument('foo', nargs='+')
    849      >>> parser.parse_args(['a', 'b'])
    850      Namespace(foo=['a', 'b'])
    851      >>> parser.parse_args([])
    852      usage: PROG [-h] foo [foo ...]
    853      PROG: error: too few arguments
    854 
    855 * ``argparse.REMAINDER``.  All the remaining command-line arguments are gathered
    856   into a list.  This is commonly useful for command line utilities that dispatch
    857   to other command line utilities::
    858 
    859      >>> parser = argparse.ArgumentParser(prog='PROG')
    860      >>> parser.add_argument('--foo')
    861      >>> parser.add_argument('command')
    862      >>> parser.add_argument('args', nargs=argparse.REMAINDER)
    863      >>> print parser.parse_args('--foo B cmd --arg1 XX ZZ'.split())
    864      Namespace(args=['--arg1', 'XX', 'ZZ'], command='cmd', foo='B')
    865 
    866 If the ``nargs`` keyword argument is not provided, the number of arguments consumed
    867 is determined by the action_.  Generally this means a single command-line argument
    868 will be consumed and a single item (not a list) will be produced.
    869 
    870 
    871 const
    872 ^^^^^
    873 
    874 The ``const`` argument of :meth:`~ArgumentParser.add_argument` is used to hold
    875 constant values that are not read from the command line but are required for
    876 the various :class:`ArgumentParser` actions.  The two most common uses of it are:
    877 
    878 * When :meth:`~ArgumentParser.add_argument` is called with
    879   ``action='store_const'`` or ``action='append_const'``.  These actions add the
    880   ``const`` value to one of the attributes of the object returned by
    881   :meth:`~ArgumentParser.parse_args`. See the action_ description for examples.
    882 
    883 * When :meth:`~ArgumentParser.add_argument` is called with option strings
    884   (like ``-f`` or ``--foo``) and ``nargs='?'``.  This creates an optional
    885   argument that can be followed by zero or one command-line arguments.
    886   When parsing the command line, if the option string is encountered with no
    887   command-line argument following it, the value of ``const`` will be assumed instead.
    888   See the nargs_ description for examples.
    889 
    890 With the ``'store_const'`` and ``'append_const'`` actions, the ``const``
    891 keyword argument must be given.  For other actions, it defaults to ``None``.
    892 
    893 
    894 default
    895 ^^^^^^^
    896 
    897 All optional arguments and some positional arguments may be omitted at the
    898 command line.  The ``default`` keyword argument of
    899 :meth:`~ArgumentParser.add_argument`, whose value defaults to ``None``,
    900 specifies what value should be used if the command-line argument is not present.
    901 For optional arguments, the ``default`` value is used when the option string
    902 was not present at the command line::
    903 
    904    >>> parser = argparse.ArgumentParser()
    905    >>> parser.add_argument('--foo', default=42)
    906    >>> parser.parse_args(['--foo', '2'])
    907    Namespace(foo='2')
    908    >>> parser.parse_args([])
    909    Namespace(foo=42)
    910 
    911 If the ``default`` value is a string, the parser parses the value as if it
    912 were a command-line argument.  In particular, the parser applies any type_
    913 conversion argument, if provided, before setting the attribute on the
    914 :class:`Namespace` return value.  Otherwise, the parser uses the value as is::
    915 
    916    >>> parser = argparse.ArgumentParser()
    917    >>> parser.add_argument('--length', default='10', type=int)
    918    >>> parser.add_argument('--width', default=10.5, type=int)
    919    >>> parser.parse_args()
    920    Namespace(length=10, width=10.5)
    921 
    922 For positional arguments with nargs_ equal to ``?`` or ``*``, the ``default`` value
    923 is used when no command-line argument was present::
    924 
    925    >>> parser = argparse.ArgumentParser()
    926    >>> parser.add_argument('foo', nargs='?', default=42)
    927    >>> parser.parse_args(['a'])
    928    Namespace(foo='a')
    929    >>> parser.parse_args([])
    930    Namespace(foo=42)
    931 
    932 
    933 Providing ``default=argparse.SUPPRESS`` causes no attribute to be added if the
    934 command-line argument was not present.::
    935 
    936    >>> parser = argparse.ArgumentParser()
    937    >>> parser.add_argument('--foo', default=argparse.SUPPRESS)
    938    >>> parser.parse_args([])
    939    Namespace()
    940    >>> parser.parse_args(['--foo', '1'])
    941    Namespace(foo='1')
    942 
    943 
    944 type
    945 ^^^^
    946 
    947 By default, :class:`ArgumentParser` objects read command-line arguments in as simple
    948 strings. However, quite often the command-line string should instead be
    949 interpreted as another type, like a :class:`float` or :class:`int`.  The
    950 ``type`` keyword argument of :meth:`~ArgumentParser.add_argument` allows any
    951 necessary type-checking and type conversions to be performed.  Common built-in
    952 types and functions can be used directly as the value of the ``type`` argument::
    953 
    954    >>> parser = argparse.ArgumentParser()
    955    >>> parser.add_argument('foo', type=int)
    956    >>> parser.add_argument('bar', type=file)
    957    >>> parser.parse_args('2 temp.txt'.split())
    958    Namespace(bar=<open file 'temp.txt', mode 'r' at 0x...>, foo=2)
    959 
    960 See the section on the default_ keyword argument for information on when the
    961 ``type`` argument is applied to default arguments.
    962 
    963 To ease the use of various types of files, the argparse module provides the
    964 factory FileType which takes the ``mode=`` and ``bufsize=`` arguments of the
    965 ``file`` object.  For example, ``FileType('w')`` can be used to create a
    966 writable file::
    967 
    968    >>> parser = argparse.ArgumentParser()
    969    >>> parser.add_argument('bar', type=argparse.FileType('w'))
    970    >>> parser.parse_args(['out.txt'])
    971    Namespace(bar=<open file 'out.txt', mode 'w' at 0x...>)
    972 
    973 ``type=`` can take any callable that takes a single string argument and returns
    974 the converted value::
    975 
    976    >>> def perfect_square(string):
    977    ...     value = int(string)
    978    ...     sqrt = math.sqrt(value)
    979    ...     if sqrt != int(sqrt):
    980    ...         msg = "%r is not a perfect square" % string
    981    ...         raise argparse.ArgumentTypeError(msg)
    982    ...     return value
    983    ...
    984    >>> parser = argparse.ArgumentParser(prog='PROG')
    985    >>> parser.add_argument('foo', type=perfect_square)
    986    >>> parser.parse_args(['9'])
    987    Namespace(foo=9)
    988    >>> parser.parse_args(['7'])
    989    usage: PROG [-h] foo
    990    PROG: error: argument foo: '7' is not a perfect square
    991 
    992 The choices_ keyword argument may be more convenient for type checkers that
    993 simply check against a range of values::
    994 
    995    >>> parser = argparse.ArgumentParser(prog='PROG')
    996    >>> parser.add_argument('foo', type=int, choices=xrange(5, 10))
    997    >>> parser.parse_args(['7'])
    998    Namespace(foo=7)
    999    >>> parser.parse_args(['11'])
   1000    usage: PROG [-h] {5,6,7,8,9}
   1001    PROG: error: argument foo: invalid choice: 11 (choose from 5, 6, 7, 8, 9)
   1002 
   1003 See the choices_ section for more details.
   1004 
   1005 
   1006 choices
   1007 ^^^^^^^
   1008 
   1009 Some command-line arguments should be selected from a restricted set of values.
   1010 These can be handled by passing a container object as the *choices* keyword
   1011 argument to :meth:`~ArgumentParser.add_argument`.  When the command line is
   1012 parsed, argument values will be checked, and an error message will be displayed
   1013 if the argument was not one of the acceptable values::
   1014 
   1015    >>> parser = argparse.ArgumentParser(prog='game.py')
   1016    >>> parser.add_argument('move', choices=['rock', 'paper', 'scissors'])
   1017    >>> parser.parse_args(['rock'])
   1018    Namespace(move='rock')
   1019    >>> parser.parse_args(['fire'])
   1020    usage: game.py [-h] {rock,paper,scissors}
   1021    game.py: error: argument move: invalid choice: 'fire' (choose from 'rock',
   1022    'paper', 'scissors')
   1023 
   1024 Note that inclusion in the *choices* container is checked after any type_
   1025 conversions have been performed, so the type of the objects in the *choices*
   1026 container should match the type_ specified::
   1027 
   1028    >>> parser = argparse.ArgumentParser(prog='doors.py')
   1029    >>> parser.add_argument('door', type=int, choices=range(1, 4))
   1030    >>> print(parser.parse_args(['3']))
   1031    Namespace(door=3)
   1032    >>> parser.parse_args(['4'])
   1033    usage: doors.py [-h] {1,2,3}
   1034    doors.py: error: argument door: invalid choice: 4 (choose from 1, 2, 3)
   1035 
   1036 Any object that supports the ``in`` operator can be passed as the *choices*
   1037 value, so :class:`dict` objects, :class:`set` objects, custom containers,
   1038 etc. are all supported.
   1039 
   1040 
   1041 required
   1042 ^^^^^^^^
   1043 
   1044 In general, the :mod:`argparse` module assumes that flags like ``-f`` and ``--bar``
   1045 indicate *optional* arguments, which can always be omitted at the command line.
   1046 To make an option *required*, ``True`` can be specified for the ``required=``
   1047 keyword argument to :meth:`~ArgumentParser.add_argument`::
   1048 
   1049    >>> parser = argparse.ArgumentParser()
   1050    >>> parser.add_argument('--foo', required=True)
   1051    >>> parser.parse_args(['--foo', 'BAR'])
   1052    Namespace(foo='BAR')
   1053    >>> parser.parse_args([])
   1054    usage: argparse.py [-h] [--foo FOO]
   1055    argparse.py: error: option --foo is required
   1056 
   1057 As the example shows, if an option is marked as ``required``,
   1058 :meth:`~ArgumentParser.parse_args` will report an error if that option is not
   1059 present at the command line.
   1060 
   1061 .. note::
   1062 
   1063     Required options are generally considered bad form because users expect
   1064     *options* to be *optional*, and thus they should be avoided when possible.
   1065 
   1066 
   1067 help
   1068 ^^^^
   1069 
   1070 The ``help`` value is a string containing a brief description of the argument.
   1071 When a user requests help (usually by using ``-h`` or ``--help`` at the
   1072 command line), these ``help`` descriptions will be displayed with each
   1073 argument::
   1074 
   1075    >>> parser = argparse.ArgumentParser(prog='frobble')
   1076    >>> parser.add_argument('--foo', action='store_true',
   1077    ...                     help='foo the bars before frobbling')
   1078    >>> parser.add_argument('bar', nargs='+',
   1079    ...                     help='one of the bars to be frobbled')
   1080    >>> parser.parse_args(['-h'])
   1081    usage: frobble [-h] [--foo] bar [bar ...]
   1082 
   1083    positional arguments:
   1084     bar     one of the bars to be frobbled
   1085 
   1086    optional arguments:
   1087     -h, --help  show this help message and exit
   1088     --foo   foo the bars before frobbling
   1089 
   1090 The ``help`` strings can include various format specifiers to avoid repetition
   1091 of things like the program name or the argument default_.  The available
   1092 specifiers include the program name, ``%(prog)s`` and most keyword arguments to
   1093 :meth:`~ArgumentParser.add_argument`, e.g. ``%(default)s``, ``%(type)s``, etc.::
   1094 
   1095    >>> parser = argparse.ArgumentParser(prog='frobble')
   1096    >>> parser.add_argument('bar', nargs='?', type=int, default=42,
   1097    ...                     help='the bar to %(prog)s (default: %(default)s)')
   1098    >>> parser.print_help()
   1099    usage: frobble [-h] [bar]
   1100 
   1101    positional arguments:
   1102     bar     the bar to frobble (default: 42)
   1103 
   1104    optional arguments:
   1105     -h, --help  show this help message and exit
   1106 
   1107 :mod:`argparse` supports silencing the help entry for certain options, by
   1108 setting the ``help`` value to ``argparse.SUPPRESS``::
   1109 
   1110    >>> parser = argparse.ArgumentParser(prog='frobble')
   1111    >>> parser.add_argument('--foo', help=argparse.SUPPRESS)
   1112    >>> parser.print_help()
   1113    usage: frobble [-h]
   1114 
   1115    optional arguments:
   1116      -h, --help  show this help message and exit
   1117 
   1118 
   1119 metavar
   1120 ^^^^^^^
   1121 
   1122 When :class:`ArgumentParser` generates help messages, it needs some way to refer
   1123 to each expected argument.  By default, ArgumentParser objects use the dest_
   1124 value as the "name" of each object.  By default, for positional argument
   1125 actions, the dest_ value is used directly, and for optional argument actions,
   1126 the dest_ value is uppercased.  So, a single positional argument with
   1127 ``dest='bar'`` will be referred to as ``bar``. A single
   1128 optional argument ``--foo`` that should be followed by a single command-line argument
   1129 will be referred to as ``FOO``.  An example::
   1130 
   1131    >>> parser = argparse.ArgumentParser()
   1132    >>> parser.add_argument('--foo')
   1133    >>> parser.add_argument('bar')
   1134    >>> parser.parse_args('X --foo Y'.split())
   1135    Namespace(bar='X', foo='Y')
   1136    >>> parser.print_help()
   1137    usage:  [-h] [--foo FOO] bar
   1138 
   1139    positional arguments:
   1140     bar
   1141 
   1142    optional arguments:
   1143     -h, --help  show this help message and exit
   1144     --foo FOO
   1145 
   1146 An alternative name can be specified with ``metavar``::
   1147 
   1148    >>> parser = argparse.ArgumentParser()
   1149    >>> parser.add_argument('--foo', metavar='YYY')
   1150    >>> parser.add_argument('bar', metavar='XXX')
   1151    >>> parser.parse_args('X --foo Y'.split())
   1152    Namespace(bar='X', foo='Y')
   1153    >>> parser.print_help()
   1154    usage:  [-h] [--foo YYY] XXX
   1155 
   1156    positional arguments:
   1157     XXX
   1158 
   1159    optional arguments:
   1160     -h, --help  show this help message and exit
   1161     --foo YYY
   1162 
   1163 Note that ``metavar`` only changes the *displayed* name - the name of the
   1164 attribute on the :meth:`~ArgumentParser.parse_args` object is still determined
   1165 by the dest_ value.
   1166 
   1167 Different values of ``nargs`` may cause the metavar to be used multiple times.
   1168 Providing a tuple to ``metavar`` specifies a different display for each of the
   1169 arguments::
   1170 
   1171    >>> parser = argparse.ArgumentParser(prog='PROG')
   1172    >>> parser.add_argument('-x', nargs=2)
   1173    >>> parser.add_argument('--foo', nargs=2, metavar=('bar', 'baz'))
   1174    >>> parser.print_help()
   1175    usage: PROG [-h] [-x X X] [--foo bar baz]
   1176 
   1177    optional arguments:
   1178     -h, --help     show this help message and exit
   1179     -x X X
   1180     --foo bar baz
   1181 
   1182 
   1183 dest
   1184 ^^^^
   1185 
   1186 Most :class:`ArgumentParser` actions add some value as an attribute of the
   1187 object returned by :meth:`~ArgumentParser.parse_args`.  The name of this
   1188 attribute is determined by the ``dest`` keyword argument of
   1189 :meth:`~ArgumentParser.add_argument`.  For positional argument actions,
   1190 ``dest`` is normally supplied as the first argument to
   1191 :meth:`~ArgumentParser.add_argument`::
   1192 
   1193    >>> parser = argparse.ArgumentParser()
   1194    >>> parser.add_argument('bar')
   1195    >>> parser.parse_args(['XXX'])
   1196    Namespace(bar='XXX')
   1197 
   1198 For optional argument actions, the value of ``dest`` is normally inferred from
   1199 the option strings.  :class:`ArgumentParser` generates the value of ``dest`` by
   1200 taking the first long option string and stripping away the initial ``--``
   1201 string.  If no long option strings were supplied, ``dest`` will be derived from
   1202 the first short option string by stripping the initial ``-`` character.  Any
   1203 internal ``-`` characters will be converted to ``_`` characters to make sure
   1204 the string is a valid attribute name.  The examples below illustrate this
   1205 behavior::
   1206 
   1207    >>> parser = argparse.ArgumentParser()
   1208    >>> parser.add_argument('-f', '--foo-bar', '--foo')
   1209    >>> parser.add_argument('-x', '-y')
   1210    >>> parser.parse_args('-f 1 -x 2'.split())
   1211    Namespace(foo_bar='1', x='2')
   1212    >>> parser.parse_args('--foo 1 -y 2'.split())
   1213    Namespace(foo_bar='1', x='2')
   1214 
   1215 ``dest`` allows a custom attribute name to be provided::
   1216 
   1217    >>> parser = argparse.ArgumentParser()
   1218    >>> parser.add_argument('--foo', dest='bar')
   1219    >>> parser.parse_args('--foo XXX'.split())
   1220    Namespace(bar='XXX')
   1221 
   1222 Action classes
   1223 ^^^^^^^^^^^^^^
   1224 
   1225 Action classes implement the Action API, a callable which returns a callable
   1226 which processes arguments from the command-line. Any object which follows this
   1227 API may be passed as the ``action`` parameter to :meth:`add_argument`.
   1228 
   1229 .. class:: Action(option_strings, dest, nargs=None, const=None, default=None, \
   1230                   type=None, choices=None, required=False, help=None, \
   1231                   metavar=None)
   1232 
   1233 Action objects are used by an ArgumentParser to represent the information needed
   1234 to parse a single argument from one or more strings from the command line. The
   1235 Action class must accept the two positional arguments plus any keyword arguments
   1236 passed to :meth:`ArgumentParser.add_argument` except for the ``action`` itself.
   1237 
   1238 Instances of Action (or return value of any callable to the ``action``
   1239 parameter) should have attributes "dest", "option_strings", "default", "type",
   1240 "required", "help", etc. defined. The easiest way to ensure these attributes
   1241 are defined is to call ``Action.__init__``.
   1242 
   1243 Action instances should be callable, so subclasses must override the
   1244 ``__call__`` method, which should accept four parameters:
   1245 
   1246 * ``parser`` - The ArgumentParser object which contains this action.
   1247 
   1248 * ``namespace`` - The :class:`Namespace` object that will be returned by
   1249   :meth:`~ArgumentParser.parse_args`.  Most actions add an attribute to this
   1250   object using :func:`setattr`.
   1251 
   1252 * ``values`` - The associated command-line arguments, with any type conversions
   1253   applied.  Type conversions are specified with the type_ keyword argument to
   1254   :meth:`~ArgumentParser.add_argument`.
   1255 
   1256 * ``option_string`` - The option string that was used to invoke this action.
   1257   The ``option_string`` argument is optional, and will be absent if the action
   1258   is associated with a positional argument.
   1259 
   1260 The ``__call__`` method may perform arbitrary actions, but will typically set
   1261 attributes on the ``namespace`` based on ``dest`` and ``values``.
   1262 
   1263 
   1264 The parse_args() method
   1265 -----------------------
   1266 
   1267 .. method:: ArgumentParser.parse_args(args=None, namespace=None)
   1268 
   1269    Convert argument strings to objects and assign them as attributes of the
   1270    namespace.  Return the populated namespace.
   1271 
   1272    Previous calls to :meth:`add_argument` determine exactly what objects are
   1273    created and how they are assigned. See the documentation for
   1274    :meth:`add_argument` for details.
   1275 
   1276    By default, the argument strings are taken from :data:`sys.argv`, and a new empty
   1277    :class:`Namespace` object is created for the attributes.
   1278 
   1279 
   1280 Option value syntax
   1281 ^^^^^^^^^^^^^^^^^^^
   1282 
   1283 The :meth:`~ArgumentParser.parse_args` method supports several ways of
   1284 specifying the value of an option (if it takes one).  In the simplest case, the
   1285 option and its value are passed as two separate arguments::
   1286 
   1287    >>> parser = argparse.ArgumentParser(prog='PROG')
   1288    >>> parser.add_argument('-x')
   1289    >>> parser.add_argument('--foo')
   1290    >>> parser.parse_args(['-x', 'X'])
   1291    Namespace(foo=None, x='X')
   1292    >>> parser.parse_args(['--foo', 'FOO'])
   1293    Namespace(foo='FOO', x=None)
   1294 
   1295 For long options (options with names longer than a single character), the option
   1296 and value can also be passed as a single command-line argument, using ``=`` to
   1297 separate them::
   1298 
   1299    >>> parser.parse_args(['--foo=FOO'])
   1300    Namespace(foo='FOO', x=None)
   1301 
   1302 For short options (options only one character long), the option and its value
   1303 can be concatenated::
   1304 
   1305    >>> parser.parse_args(['-xX'])
   1306    Namespace(foo=None, x='X')
   1307 
   1308 Several short options can be joined together, using only a single ``-`` prefix,
   1309 as long as only the last option (or none of them) requires a value::
   1310 
   1311    >>> parser = argparse.ArgumentParser(prog='PROG')
   1312    >>> parser.add_argument('-x', action='store_true')
   1313    >>> parser.add_argument('-y', action='store_true')
   1314    >>> parser.add_argument('-z')
   1315    >>> parser.parse_args(['-xyzZ'])
   1316    Namespace(x=True, y=True, z='Z')
   1317 
   1318 
   1319 Invalid arguments
   1320 ^^^^^^^^^^^^^^^^^
   1321 
   1322 While parsing the command line, :meth:`~ArgumentParser.parse_args` checks for a
   1323 variety of errors, including ambiguous options, invalid types, invalid options,
   1324 wrong number of positional arguments, etc.  When it encounters such an error,
   1325 it exits and prints the error along with a usage message::
   1326 
   1327    >>> parser = argparse.ArgumentParser(prog='PROG')
   1328    >>> parser.add_argument('--foo', type=int)
   1329    >>> parser.add_argument('bar', nargs='?')
   1330 
   1331    >>> # invalid type
   1332    >>> parser.parse_args(['--foo', 'spam'])
   1333    usage: PROG [-h] [--foo FOO] [bar]
   1334    PROG: error: argument --foo: invalid int value: 'spam'
   1335 
   1336    >>> # invalid option
   1337    >>> parser.parse_args(['--bar'])
   1338    usage: PROG [-h] [--foo FOO] [bar]
   1339    PROG: error: no such option: --bar
   1340 
   1341    >>> # wrong number of arguments
   1342    >>> parser.parse_args(['spam', 'badger'])
   1343    usage: PROG [-h] [--foo FOO] [bar]
   1344    PROG: error: extra arguments found: badger
   1345 
   1346 
   1347 Arguments containing ``-``
   1348 ^^^^^^^^^^^^^^^^^^^^^^^^^^
   1349 
   1350 The :meth:`~ArgumentParser.parse_args` method attempts to give errors whenever
   1351 the user has clearly made a mistake, but some situations are inherently
   1352 ambiguous.  For example, the command-line argument ``-1`` could either be an
   1353 attempt to specify an option or an attempt to provide a positional argument.
   1354 The :meth:`~ArgumentParser.parse_args` method is cautious here: positional
   1355 arguments may only begin with ``-`` if they look like negative numbers and
   1356 there are no options in the parser that look like negative numbers::
   1357 
   1358    >>> parser = argparse.ArgumentParser(prog='PROG')
   1359    >>> parser.add_argument('-x')
   1360    >>> parser.add_argument('foo', nargs='?')
   1361 
   1362    >>> # no negative number options, so -1 is a positional argument
   1363    >>> parser.parse_args(['-x', '-1'])
   1364    Namespace(foo=None, x='-1')
   1365 
   1366    >>> # no negative number options, so -1 and -5 are positional arguments
   1367    >>> parser.parse_args(['-x', '-1', '-5'])
   1368    Namespace(foo='-5', x='-1')
   1369 
   1370    >>> parser = argparse.ArgumentParser(prog='PROG')
   1371    >>> parser.add_argument('-1', dest='one')
   1372    >>> parser.add_argument('foo', nargs='?')
   1373 
   1374    >>> # negative number options present, so -1 is an option
   1375    >>> parser.parse_args(['-1', 'X'])
   1376    Namespace(foo=None, one='X')
   1377 
   1378    >>> # negative number options present, so -2 is an option
   1379    >>> parser.parse_args(['-2'])
   1380    usage: PROG [-h] [-1 ONE] [foo]
   1381    PROG: error: no such option: -2
   1382 
   1383    >>> # negative number options present, so both -1s are options
   1384    >>> parser.parse_args(['-1', '-1'])
   1385    usage: PROG [-h] [-1 ONE] [foo]
   1386    PROG: error: argument -1: expected one argument
   1387 
   1388 If you have positional arguments that must begin with ``-`` and don't look
   1389 like negative numbers, you can insert the pseudo-argument ``'--'`` which tells
   1390 :meth:`~ArgumentParser.parse_args` that everything after that is a positional
   1391 argument::
   1392 
   1393    >>> parser.parse_args(['--', '-f'])
   1394    Namespace(foo='-f', one=None)
   1395 
   1396 .. _prefix-matching:
   1397 
   1398 Argument abbreviations (prefix matching)
   1399 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   1400 
   1401 The :meth:`~ArgumentParser.parse_args` method allows long options to be
   1402 abbreviated to a prefix, if the abbreviation is unambiguous (the prefix matches
   1403 a unique option)::
   1404 
   1405    >>> parser = argparse.ArgumentParser(prog='PROG')
   1406    >>> parser.add_argument('-bacon')
   1407    >>> parser.add_argument('-badger')
   1408    >>> parser.parse_args('-bac MMM'.split())
   1409    Namespace(bacon='MMM', badger=None)
   1410    >>> parser.parse_args('-bad WOOD'.split())
   1411    Namespace(bacon=None, badger='WOOD')
   1412    >>> parser.parse_args('-ba BA'.split())
   1413    usage: PROG [-h] [-bacon BACON] [-badger BADGER]
   1414    PROG: error: ambiguous option: -ba could match -badger, -bacon
   1415 
   1416 An error is produced for arguments that could produce more than one options.
   1417 
   1418 
   1419 Beyond ``sys.argv``
   1420 ^^^^^^^^^^^^^^^^^^^
   1421 
   1422 Sometimes it may be useful to have an ArgumentParser parse arguments other than those
   1423 of :data:`sys.argv`.  This can be accomplished by passing a list of strings to
   1424 :meth:`~ArgumentParser.parse_args`.  This is useful for testing at the
   1425 interactive prompt::
   1426 
   1427    >>> parser = argparse.ArgumentParser()
   1428    >>> parser.add_argument(
   1429    ...     'integers', metavar='int', type=int, choices=xrange(10),
   1430    ...     nargs='+', help='an integer in the range 0..9')
   1431    >>> parser.add_argument(
   1432    ...     '--sum', dest='accumulate', action='store_const', const=sum,
   1433    ...     default=max, help='sum the integers (default: find the max)')
   1434    >>> parser.parse_args(['1', '2', '3', '4'])
   1435    Namespace(accumulate=<built-in function max>, integers=[1, 2, 3, 4])
   1436    >>> parser.parse_args(['1', '2', '3', '4', '--sum'])
   1437    Namespace(accumulate=<built-in function sum>, integers=[1, 2, 3, 4])
   1438 
   1439 
   1440 The Namespace object
   1441 ^^^^^^^^^^^^^^^^^^^^
   1442 
   1443 .. class:: Namespace
   1444 
   1445    Simple class used by default by :meth:`~ArgumentParser.parse_args` to create
   1446    an object holding attributes and return it.
   1447 
   1448 This class is deliberately simple, just an :class:`object` subclass with a
   1449 readable string representation. If you prefer to have dict-like view of the
   1450 attributes, you can use the standard Python idiom, :func:`vars`::
   1451 
   1452    >>> parser = argparse.ArgumentParser()
   1453    >>> parser.add_argument('--foo')
   1454    >>> args = parser.parse_args(['--foo', 'BAR'])
   1455    >>> vars(args)
   1456    {'foo': 'BAR'}
   1457 
   1458 It may also be useful to have an :class:`ArgumentParser` assign attributes to an
   1459 already existing object, rather than a new :class:`Namespace` object.  This can
   1460 be achieved by specifying the ``namespace=`` keyword argument::
   1461 
   1462    >>> class C(object):
   1463    ...     pass
   1464    ...
   1465    >>> c = C()
   1466    >>> parser = argparse.ArgumentParser()
   1467    >>> parser.add_argument('--foo')
   1468    >>> parser.parse_args(args=['--foo', 'BAR'], namespace=c)
   1469    >>> c.foo
   1470    'BAR'
   1471 
   1472 
   1473 Other utilities
   1474 ---------------
   1475 
   1476 Sub-commands
   1477 ^^^^^^^^^^^^
   1478 
   1479 .. method:: ArgumentParser.add_subparsers([title], [description], [prog], \
   1480                                           [parser_class], [action], \
   1481                                           [option_string], [dest], [help], \
   1482                                           [metavar])
   1483 
   1484    Many programs split up their functionality into a number of sub-commands,
   1485    for example, the ``svn`` program can invoke sub-commands like ``svn
   1486    checkout``, ``svn update``, and ``svn commit``.  Splitting up functionality
   1487    this way can be a particularly good idea when a program performs several
   1488    different functions which require different kinds of command-line arguments.
   1489    :class:`ArgumentParser` supports the creation of such sub-commands with the
   1490    :meth:`add_subparsers` method.  The :meth:`add_subparsers` method is normally
   1491    called with no arguments and returns a special action object.  This object
   1492    has a single method, :meth:`~ArgumentParser.add_parser`, which takes a
   1493    command name and any :class:`ArgumentParser` constructor arguments, and
   1494    returns an :class:`ArgumentParser` object that can be modified as usual.
   1495 
   1496    Description of parameters:
   1497 
   1498    * title - title for the sub-parser group in help output; by default
   1499      "subcommands" if description is provided, otherwise uses title for
   1500      positional arguments
   1501 
   1502    * description - description for the sub-parser group in help output, by
   1503      default ``None``
   1504 
   1505    * prog - usage information that will be displayed with sub-command help,
   1506      by default the name of the program and any positional arguments before the
   1507      subparser argument
   1508 
   1509    * parser_class - class which will be used to create sub-parser instances, by
   1510      default the class of the current parser (e.g. ArgumentParser)
   1511 
   1512    * action_ - the basic type of action to be taken when this argument is
   1513      encountered at the command line
   1514 
   1515    * dest_ - name of the attribute under which sub-command name will be
   1516      stored; by default ``None`` and no value is stored
   1517 
   1518    * help_ - help for sub-parser group in help output, by default ``None``
   1519 
   1520    * metavar_ - string presenting available sub-commands in help; by default it
   1521      is ``None`` and presents sub-commands in form {cmd1, cmd2, ..}
   1522 
   1523    Some example usage::
   1524 
   1525      >>> # create the top-level parser
   1526      >>> parser = argparse.ArgumentParser(prog='PROG')
   1527      >>> parser.add_argument('--foo', action='store_true', help='foo help')
   1528      >>> subparsers = parser.add_subparsers(help='sub-command help')
   1529      >>>
   1530      >>> # create the parser for the "a" command
   1531      >>> parser_a = subparsers.add_parser('a', help='a help')
   1532      >>> parser_a.add_argument('bar', type=int, help='bar help')
   1533      >>>
   1534      >>> # create the parser for the "b" command
   1535      >>> parser_b = subparsers.add_parser('b', help='b help')
   1536      >>> parser_b.add_argument('--baz', choices='XYZ', help='baz help')
   1537      >>>
   1538      >>> # parse some argument lists
   1539      >>> parser.parse_args(['a', '12'])
   1540      Namespace(bar=12, foo=False)
   1541      >>> parser.parse_args(['--foo', 'b', '--baz', 'Z'])
   1542      Namespace(baz='Z', foo=True)
   1543 
   1544    Note that the object returned by :meth:`parse_args` will only contain
   1545    attributes for the main parser and the subparser that was selected by the
   1546    command line (and not any other subparsers).  So in the example above, when
   1547    the ``a`` command is specified, only the ``foo`` and ``bar`` attributes are
   1548    present, and when the ``b`` command is specified, only the ``foo`` and
   1549    ``baz`` attributes are present.
   1550 
   1551    Similarly, when a help message is requested from a subparser, only the help
   1552    for that particular parser will be printed.  The help message will not
   1553    include parent parser or sibling parser messages.  (A help message for each
   1554    subparser command, however, can be given by supplying the ``help=`` argument
   1555    to :meth:`add_parser` as above.)
   1556 
   1557    ::
   1558 
   1559      >>> parser.parse_args(['--help'])
   1560      usage: PROG [-h] [--foo] {a,b} ...
   1561 
   1562      positional arguments:
   1563        {a,b}   sub-command help
   1564          a     a help
   1565          b     b help
   1566 
   1567      optional arguments:
   1568        -h, --help  show this help message and exit
   1569        --foo   foo help
   1570 
   1571      >>> parser.parse_args(['a', '--help'])
   1572      usage: PROG a [-h] bar
   1573 
   1574      positional arguments:
   1575        bar     bar help
   1576 
   1577      optional arguments:
   1578        -h, --help  show this help message and exit
   1579 
   1580      >>> parser.parse_args(['b', '--help'])
   1581      usage: PROG b [-h] [--baz {X,Y,Z}]
   1582 
   1583      optional arguments:
   1584        -h, --help     show this help message and exit
   1585        --baz {X,Y,Z}  baz help
   1586 
   1587    The :meth:`add_subparsers` method also supports ``title`` and ``description``
   1588    keyword arguments.  When either is present, the subparser's commands will
   1589    appear in their own group in the help output.  For example::
   1590 
   1591      >>> parser = argparse.ArgumentParser()
   1592      >>> subparsers = parser.add_subparsers(title='subcommands',
   1593      ...                                    description='valid subcommands',
   1594      ...                                    help='additional help')
   1595      >>> subparsers.add_parser('foo')
   1596      >>> subparsers.add_parser('bar')
   1597      >>> parser.parse_args(['-h'])
   1598      usage:  [-h] {foo,bar} ...
   1599 
   1600      optional arguments:
   1601        -h, --help  show this help message and exit
   1602 
   1603      subcommands:
   1604        valid subcommands
   1605 
   1606        {foo,bar}   additional help
   1607 
   1608 
   1609    One particularly effective way of handling sub-commands is to combine the use
   1610    of the :meth:`add_subparsers` method with calls to :meth:`set_defaults` so
   1611    that each subparser knows which Python function it should execute.  For
   1612    example::
   1613 
   1614      >>> # sub-command functions
   1615      >>> def foo(args):
   1616      ...     print args.x * args.y
   1617      ...
   1618      >>> def bar(args):
   1619      ...     print '((%s))' % args.z
   1620      ...
   1621      >>> # create the top-level parser
   1622      >>> parser = argparse.ArgumentParser()
   1623      >>> subparsers = parser.add_subparsers()
   1624      >>>
   1625      >>> # create the parser for the "foo" command
   1626      >>> parser_foo = subparsers.add_parser('foo')
   1627      >>> parser_foo.add_argument('-x', type=int, default=1)
   1628      >>> parser_foo.add_argument('y', type=float)
   1629      >>> parser_foo.set_defaults(func=foo)
   1630      >>>
   1631      >>> # create the parser for the "bar" command
   1632      >>> parser_bar = subparsers.add_parser('bar')
   1633      >>> parser_bar.add_argument('z')
   1634      >>> parser_bar.set_defaults(func=bar)
   1635      >>>
   1636      >>> # parse the args and call whatever function was selected
   1637      >>> args = parser.parse_args('foo 1 -x 2'.split())
   1638      >>> args.func(args)
   1639      2.0
   1640      >>>
   1641      >>> # parse the args and call whatever function was selected
   1642      >>> args = parser.parse_args('bar XYZYX'.split())
   1643      >>> args.func(args)
   1644      ((XYZYX))
   1645 
   1646    This way, you can let :meth:`parse_args` do the job of calling the
   1647    appropriate function after argument parsing is complete.  Associating
   1648    functions with actions like this is typically the easiest way to handle the
   1649    different actions for each of your subparsers.  However, if it is necessary
   1650    to check the name of the subparser that was invoked, the ``dest`` keyword
   1651    argument to the :meth:`add_subparsers` call will work::
   1652 
   1653      >>> parser = argparse.ArgumentParser()
   1654      >>> subparsers = parser.add_subparsers(dest='subparser_name')
   1655      >>> subparser1 = subparsers.add_parser('1')
   1656      >>> subparser1.add_argument('-x')
   1657      >>> subparser2 = subparsers.add_parser('2')
   1658      >>> subparser2.add_argument('y')
   1659      >>> parser.parse_args(['2', 'frobble'])
   1660      Namespace(subparser_name='2', y='frobble')
   1661 
   1662 
   1663 FileType objects
   1664 ^^^^^^^^^^^^^^^^
   1665 
   1666 .. class:: FileType(mode='r', bufsize=None)
   1667 
   1668    The :class:`FileType` factory creates objects that can be passed to the type
   1669    argument of :meth:`ArgumentParser.add_argument`.  Arguments that have
   1670    :class:`FileType` objects as their type will open command-line arguments as files
   1671    with the requested modes and buffer sizes::
   1672 
   1673       >>> parser = argparse.ArgumentParser()
   1674       >>> parser.add_argument('--output', type=argparse.FileType('wb', 0))
   1675       >>> parser.parse_args(['--output', 'out'])
   1676       Namespace(output=<open file 'out', mode 'wb' at 0x...>)
   1677 
   1678    FileType objects understand the pseudo-argument ``'-'`` and automatically
   1679    convert this into ``sys.stdin`` for readable :class:`FileType` objects and
   1680    ``sys.stdout`` for writable :class:`FileType` objects::
   1681 
   1682       >>> parser = argparse.ArgumentParser()
   1683       >>> parser.add_argument('infile', type=argparse.FileType('r'))
   1684       >>> parser.parse_args(['-'])
   1685       Namespace(infile=<open file '<stdin>', mode 'r' at 0x...>)
   1686 
   1687 
   1688 Argument groups
   1689 ^^^^^^^^^^^^^^^
   1690 
   1691 .. method:: ArgumentParser.add_argument_group(title=None, description=None)
   1692 
   1693    By default, :class:`ArgumentParser` groups command-line arguments into
   1694    "positional arguments" and "optional arguments" when displaying help
   1695    messages. When there is a better conceptual grouping of arguments than this
   1696    default one, appropriate groups can be created using the
   1697    :meth:`add_argument_group` method::
   1698 
   1699      >>> parser = argparse.ArgumentParser(prog='PROG', add_help=False)
   1700      >>> group = parser.add_argument_group('group')
   1701      >>> group.add_argument('--foo', help='foo help')
   1702      >>> group.add_argument('bar', help='bar help')
   1703      >>> parser.print_help()
   1704      usage: PROG [--foo FOO] bar
   1705 
   1706      group:
   1707        bar    bar help
   1708        --foo FOO  foo help
   1709 
   1710    The :meth:`add_argument_group` method returns an argument group object which
   1711    has an :meth:`~ArgumentParser.add_argument` method just like a regular
   1712    :class:`ArgumentParser`.  When an argument is added to the group, the parser
   1713    treats it just like a normal argument, but displays the argument in a
   1714    separate group for help messages.  The :meth:`add_argument_group` method
   1715    accepts *title* and *description* arguments which can be used to
   1716    customize this display::
   1717 
   1718      >>> parser = argparse.ArgumentParser(prog='PROG', add_help=False)
   1719      >>> group1 = parser.add_argument_group('group1', 'group1 description')
   1720      >>> group1.add_argument('foo', help='foo help')
   1721      >>> group2 = parser.add_argument_group('group2', 'group2 description')
   1722      >>> group2.add_argument('--bar', help='bar help')
   1723      >>> parser.print_help()
   1724      usage: PROG [--bar BAR] foo
   1725 
   1726      group1:
   1727        group1 description
   1728 
   1729        foo    foo help
   1730 
   1731      group2:
   1732        group2 description
   1733 
   1734        --bar BAR  bar help
   1735 
   1736    Note that any arguments not in your user-defined groups will end up back
   1737    in the usual "positional arguments" and "optional arguments" sections.
   1738 
   1739 
   1740 Mutual exclusion
   1741 ^^^^^^^^^^^^^^^^
   1742 
   1743 .. method:: ArgumentParser.add_mutually_exclusive_group(required=False)
   1744 
   1745    Create a mutually exclusive group. :mod:`argparse` will make sure that only
   1746    one of the arguments in the mutually exclusive group was present on the
   1747    command line::
   1748 
   1749      >>> parser = argparse.ArgumentParser(prog='PROG')
   1750      >>> group = parser.add_mutually_exclusive_group()
   1751      >>> group.add_argument('--foo', action='store_true')
   1752      >>> group.add_argument('--bar', action='store_false')
   1753      >>> parser.parse_args(['--foo'])
   1754      Namespace(bar=True, foo=True)
   1755      >>> parser.parse_args(['--bar'])
   1756      Namespace(bar=False, foo=False)
   1757      >>> parser.parse_args(['--foo', '--bar'])
   1758      usage: PROG [-h] [--foo | --bar]
   1759      PROG: error: argument --bar: not allowed with argument --foo
   1760 
   1761    The :meth:`add_mutually_exclusive_group` method also accepts a *required*
   1762    argument, to indicate that at least one of the mutually exclusive arguments
   1763    is required::
   1764 
   1765      >>> parser = argparse.ArgumentParser(prog='PROG')
   1766      >>> group = parser.add_mutually_exclusive_group(required=True)
   1767      >>> group.add_argument('--foo', action='store_true')
   1768      >>> group.add_argument('--bar', action='store_false')
   1769      >>> parser.parse_args([])
   1770      usage: PROG [-h] (--foo | --bar)
   1771      PROG: error: one of the arguments --foo --bar is required
   1772 
   1773    Note that currently mutually exclusive argument groups do not support the
   1774    *title* and *description* arguments of
   1775    :meth:`~ArgumentParser.add_argument_group`.
   1776 
   1777 
   1778 Parser defaults
   1779 ^^^^^^^^^^^^^^^
   1780 
   1781 .. method:: ArgumentParser.set_defaults(**kwargs)
   1782 
   1783    Most of the time, the attributes of the object returned by :meth:`parse_args`
   1784    will be fully determined by inspecting the command-line arguments and the argument
   1785    actions.  :meth:`set_defaults` allows some additional
   1786    attributes that are determined without any inspection of the command line to
   1787    be added::
   1788 
   1789      >>> parser = argparse.ArgumentParser()
   1790      >>> parser.add_argument('foo', type=int)
   1791      >>> parser.set_defaults(bar=42, baz='badger')
   1792      >>> parser.parse_args(['736'])
   1793      Namespace(bar=42, baz='badger', foo=736)
   1794 
   1795    Note that parser-level defaults always override argument-level defaults::
   1796 
   1797      >>> parser = argparse.ArgumentParser()
   1798      >>> parser.add_argument('--foo', default='bar')
   1799      >>> parser.set_defaults(foo='spam')
   1800      >>> parser.parse_args([])
   1801      Namespace(foo='spam')
   1802 
   1803    Parser-level defaults can be particularly useful when working with multiple
   1804    parsers.  See the :meth:`~ArgumentParser.add_subparsers` method for an
   1805    example of this type.
   1806 
   1807 .. method:: ArgumentParser.get_default(dest)
   1808 
   1809    Get the default value for a namespace attribute, as set by either
   1810    :meth:`~ArgumentParser.add_argument` or by
   1811    :meth:`~ArgumentParser.set_defaults`::
   1812 
   1813      >>> parser = argparse.ArgumentParser()
   1814      >>> parser.add_argument('--foo', default='badger')
   1815      >>> parser.get_default('foo')
   1816      'badger'
   1817 
   1818 
   1819 Printing help
   1820 ^^^^^^^^^^^^^
   1821 
   1822 In most typical applications, :meth:`~ArgumentParser.parse_args` will take
   1823 care of formatting and printing any usage or error messages.  However, several
   1824 formatting methods are available:
   1825 
   1826 .. method:: ArgumentParser.print_usage(file=None)
   1827 
   1828    Print a brief description of how the :class:`ArgumentParser` should be
   1829    invoked on the command line.  If *file* is ``None``, :data:`sys.stdout` is
   1830    assumed.
   1831 
   1832 .. method:: ArgumentParser.print_help(file=None)
   1833 
   1834    Print a help message, including the program usage and information about the
   1835    arguments registered with the :class:`ArgumentParser`.  If *file* is
   1836    ``None``, :data:`sys.stdout` is assumed.
   1837 
   1838 There are also variants of these methods that simply return a string instead of
   1839 printing it:
   1840 
   1841 .. method:: ArgumentParser.format_usage()
   1842 
   1843    Return a string containing a brief description of how the
   1844    :class:`ArgumentParser` should be invoked on the command line.
   1845 
   1846 .. method:: ArgumentParser.format_help()
   1847 
   1848    Return a string containing a help message, including the program usage and
   1849    information about the arguments registered with the :class:`ArgumentParser`.
   1850 
   1851 
   1852 Partial parsing
   1853 ^^^^^^^^^^^^^^^
   1854 
   1855 .. method:: ArgumentParser.parse_known_args(args=None, namespace=None)
   1856 
   1857 Sometimes a script may only parse a few of the command-line arguments, passing
   1858 the remaining arguments on to another script or program. In these cases, the
   1859 :meth:`~ArgumentParser.parse_known_args` method can be useful.  It works much like
   1860 :meth:`~ArgumentParser.parse_args` except that it does not produce an error when
   1861 extra arguments are present.  Instead, it returns a two item tuple containing
   1862 the populated namespace and the list of remaining argument strings.
   1863 
   1864 ::
   1865 
   1866    >>> parser = argparse.ArgumentParser()
   1867    >>> parser.add_argument('--foo', action='store_true')
   1868    >>> parser.add_argument('bar')
   1869    >>> parser.parse_known_args(['--foo', '--badger', 'BAR', 'spam'])
   1870    (Namespace(bar='BAR', foo=True), ['--badger', 'spam'])
   1871 
   1872 .. warning::
   1873    :ref:`Prefix matching <prefix-matching>` rules apply to
   1874    :meth:`parse_known_args`. The parser may consume an option even if it's just
   1875    a prefix of one of its known options, instead of leaving it in the remaining
   1876    arguments list.
   1877 
   1878 
   1879 Customizing file parsing
   1880 ^^^^^^^^^^^^^^^^^^^^^^^^
   1881 
   1882 .. method:: ArgumentParser.convert_arg_line_to_args(arg_line)
   1883 
   1884    Arguments that are read from a file (see the *fromfile_prefix_chars*
   1885    keyword argument to the :class:`ArgumentParser` constructor) are read one
   1886    argument per line. :meth:`convert_arg_line_to_args` can be overridden for
   1887    fancier reading.
   1888 
   1889    This method takes a single argument *arg_line* which is a string read from
   1890    the argument file.  It returns a list of arguments parsed from this string.
   1891    The method is called once per line read from the argument file, in order.
   1892 
   1893    A useful override of this method is one that treats each space-separated word
   1894    as an argument::
   1895 
   1896     def convert_arg_line_to_args(self, arg_line):
   1897         return arg_line.split()
   1898 
   1899 
   1900 Exiting methods
   1901 ^^^^^^^^^^^^^^^
   1902 
   1903 .. method:: ArgumentParser.exit(status=0, message=None)
   1904 
   1905    This method terminates the program, exiting with the specified *status*
   1906    and, if given, it prints a *message* before that.
   1907 
   1908 .. method:: ArgumentParser.error(message)
   1909 
   1910    This method prints a usage message including the *message* to the
   1911    standard error and terminates the program with a status code of 2.
   1912 
   1913 
   1914 .. _argparse-from-optparse:
   1915 
   1916 Upgrading optparse code
   1917 -----------------------
   1918 
   1919 Originally, the :mod:`argparse` module had attempted to maintain compatibility
   1920 with :mod:`optparse`.  However, :mod:`optparse` was difficult to extend
   1921 transparently, particularly with the changes required to support the new
   1922 ``nargs=`` specifiers and better usage messages.  When most everything in
   1923 :mod:`optparse` had either been copy-pasted over or monkey-patched, it no
   1924 longer seemed practical to try to maintain the backwards compatibility.
   1925 
   1926 The :mod:`argparse` module improves on the standard library :mod:`optparse`
   1927 module in a number of ways including:
   1928 
   1929 * Handling positional arguments.
   1930 * Supporting sub-commands.
   1931 * Allowing alternative option prefixes like ``+`` and ``/``.
   1932 * Handling zero-or-more and one-or-more style arguments.
   1933 * Producing more informative usage messages.
   1934 * Providing a much simpler interface for custom ``type`` and ``action``.
   1935 
   1936 A partial upgrade path from :mod:`optparse` to :mod:`argparse`:
   1937 
   1938 * Replace all :meth:`optparse.OptionParser.add_option` calls with
   1939   :meth:`ArgumentParser.add_argument` calls.
   1940 
   1941 * Replace ``(options, args) = parser.parse_args()`` with ``args =
   1942   parser.parse_args()`` and add additional :meth:`ArgumentParser.add_argument`
   1943   calls for the positional arguments. Keep in mind that what was previously
   1944   called ``options``, now in :mod:`argparse` context is called ``args``.
   1945 
   1946 * Replace callback actions and the ``callback_*`` keyword arguments with
   1947   ``type`` or ``action`` arguments.
   1948 
   1949 * Replace string names for ``type`` keyword arguments with the corresponding
   1950   type objects (e.g. int, float, complex, etc).
   1951 
   1952 * Replace :class:`optparse.Values` with :class:`Namespace` and
   1953   :exc:`optparse.OptionError` and :exc:`optparse.OptionValueError` with
   1954   :exc:`ArgumentError`.
   1955 
   1956 * Replace strings with implicit arguments such as ``%default`` or ``%prog`` with
   1957   the standard Python syntax to use dictionaries to format strings, that is,
   1958   ``%(default)s`` and ``%(prog)s``.
   1959 
   1960 * Replace the OptionParser constructor ``version`` argument with a call to
   1961   ``parser.add_argument('--version', action='version', version='<the version>')``.
   1962