• Home
  • Line#
  • Scopes#
  • Navigate#
  • Raw
  • Download
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@gmail.com>
7.. sectionauthor:: Steven Bethard <steven.bethard@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
21The :mod:`argparse` module makes it easy to write user-friendly command-line
22interfaces. The program defines what arguments it requires, and :mod:`argparse`
23will figure out how to parse those out of :data:`sys.argv`.  The :mod:`argparse`
24module also automatically generates help and usage messages and issues errors
25when users give the program invalid arguments.
26
27
28Example
29-------
30
31The following code is a Python program that takes a list of integers and
32produces 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
46Assuming the Python code above is saved into a file called ``prog.py``, it can
47be 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
63When run with the appropriate arguments, it prints either the sum or the max of
64the 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
74If 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
82The following sections walk you through this example.
83
84
85Creating a parser
86^^^^^^^^^^^^^^^^^
87
88The first step in using the :mod:`argparse` is creating an
89:class:`ArgumentParser` object::
90
91   >>> parser = argparse.ArgumentParser(description='Process some integers.')
92
93The :class:`ArgumentParser` object will hold all the information necessary to
94parse the command line into Python data types.
95
96
97Adding arguments
98^^^^^^^^^^^^^^^^
99
100Filling an :class:`ArgumentParser` with information about program arguments is
101done by making calls to the :meth:`~ArgumentParser.add_argument` method.
102Generally, these calls tell the :class:`ArgumentParser` how to take the strings
103on the command line and turn them into objects.  This information is stored and
104used 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
112Later, calling :meth:`~ArgumentParser.parse_args` will return an object with
113two attributes, ``integers`` and ``accumulate``.  The ``integers`` attribute
114will be a list of one or more ints, and the ``accumulate`` attribute will be
115either the :func:`sum` function, if ``--sum`` was specified at the command line,
116or the :func:`max` function if it was not.
117
118
119Parsing arguments
120^^^^^^^^^^^^^^^^^
121
122:class:`ArgumentParser` parses arguments through the
123:meth:`~ArgumentParser.parse_args` method.  This will inspect the command line,
124convert each argument to the appropriate type and then invoke the appropriate action.
125In most cases, this means a simple :class:`Namespace` object will be built up from
126attributes 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
131In a script, :meth:`~ArgumentParser.parse_args` will typically be called with no
132arguments, and the :class:`ArgumentParser` will automatically determine the
133command-line arguments from :data:`sys.argv`.
134
135
136ArgumentParser 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
178The following sections describe how each of these are used.
179
180
181prog
182^^^^
183
184By default, :class:`ArgumentParser` objects use ``sys.argv[0]`` to determine
185how to display the name of the program in help messages.  This default is almost
186always desirable because it will make the help messages match how the program was
187invoked 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
195The 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
214To 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
224Note 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
226specifier.
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
240usage
241^^^^^
242
243By default, :class:`ArgumentParser` calculates the usage message from the
244arguments 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
259The 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
274The ``%(prog)s`` format specifier is available to fill in the program name in
275your usage messages.
276
277
278description
279^^^^^^^^^^^
280
281Most calls to the :class:`ArgumentParser` constructor will use the
282``description=`` keyword argument.  This argument gives a brief description of
283what the program does and how it works.  In help messages, the description is
284displayed between the command-line usage string and the help messages for the
285various 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
296By default, the description will be line-wrapped so that it fits within the
297given space.  To change this behavior, see the formatter_class_ argument.
298
299
300epilog
301^^^^^^
302
303Some programs like to display additional description of the program after the
304description of the arguments.  Such text can be specified using the ``epilog=``
305argument 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
320As with the description_ argument, the ``epilog=`` text is by default
321line-wrapped, but this behavior can be adjusted with the formatter_class_
322argument to :class:`ArgumentParser`.
323
324
325parents
326^^^^^^^
327
328Sometimes, several parsers share a common set of arguments. Rather than
329repeating the definitions of these arguments, a single parser with all the
330shared arguments and passed to ``parents=`` argument to :class:`ArgumentParser`
331can be used.  The ``parents=`` argument takes a list of :class:`ArgumentParser`
332objects, collects all the positional and optional actions from them, and adds
333these 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
348Note that most parent parsers will specify ``add_help=False``.  Otherwise, the
349:class:`ArgumentParser` will see two ``-h/--help`` options (one in the parent
350and 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
358formatter_class
359^^^^^^^^^^^^^^^
360
361:class:`ArgumentParser` objects allow the help formatting to be customized by
362specifying an alternate formatting class.  Currently, there are three such
363classes:
364
365.. class:: RawDescriptionHelpFormatter
366           RawTextHelpFormatter
367           ArgumentDefaultsHelpFormatter
368
369The first two allow more control over how textual descriptions are displayed,
370while the last automatically adds information about argument default values.
371
372By default, :class:`ArgumentParser` objects line-wrap the description_ and
373epilog_ 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
395Passing :class:`RawDescriptionHelpFormatter` as ``formatter_class=``
396indicates that description_ and epilog_ are already correctly formatted and
397should 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,
422including argument descriptions.
423
424The other formatter class available, :class:`ArgumentDefaultsHelpFormatter`,
425will 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
443prefix_chars
444^^^^^^^^^^^^
445
446Most command-line options will use ``-`` as the prefix, e.g. ``-f/--foo``.
447Parsers that need to support different or additional prefix
448characters, e.g. for options
449like ``+f`` or ``/foo``, may specify them using the ``prefix_chars=`` argument
450to 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
458The ``prefix_chars=`` argument defaults to ``'-'``. Supplying a set of
459characters that does not include ``-`` will cause ``-f/--foo`` options to be
460disallowed.
461
462
463fromfile_prefix_chars
464^^^^^^^^^^^^^^^^^^^^^
465
466Sometimes, for example when dealing with a particularly long argument lists, it
467may make sense to keep the list of arguments in a file rather than typing it out
468at 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
470specified characters will be treated as files, and will be replaced by the
471arguments 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
480Arguments 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
482were in the same place as the original file referencing argument on the command
483line.  So in the example above, the expression ``['-f', 'foo', '@args.txt']``
484is considered equivalent to the expression ``['-f', 'foo', '-f', 'bar']``.
485
486The ``fromfile_prefix_chars=`` argument defaults to ``None``, meaning that
487arguments will never be treated as file references.
488
489
490argument_default
491^^^^^^^^^^^^^^^^
492
493Generally, 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
496pairs.  Sometimes however, it may be useful to specify a single parser-wide
497default for arguments.  This can be accomplished by passing the
498``argument_default=`` keyword argument to :class:`ArgumentParser`.  For example,
499to globally suppress attribute creation on :meth:`~ArgumentParser.parse_args`
500calls, 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
511conflict_handler
512^^^^^^^^^^^^^^^^
513
514:class:`ArgumentParser` objects do not allow two actions with the same option
515string.  By default, :class:`ArgumentParser` objects raise an exception if an
516attempt is made to create an argument with an option string that is already in
517use::
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
526Sometimes (e.g. when using parents_) it may be useful to simply override any
527older 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
542Note that :class:`ArgumentParser` objects only remove an action if all of its
543option strings are overridden.  So, in the example above, the old ``-f/--foo``
544action is retained as the ``-f`` action, because only the ``--foo`` option
545string was overridden.
546
547
548add_help
549^^^^^^^^
550
551By default, ArgumentParser objects add an option which simply displays
552the 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
560If ``-h`` or ``--help`` is supplied at the command line, the ArgumentParser
561help 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
572Occasionally, it may be useful to disable the addition of this help option.
573This 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
584The help option is typically ``-h/--help``. The exception to this is
585if the ``prefix_chars=`` is specified and does not include ``-``, in
586which case ``-h`` and ``--help`` are not valid options.  In
587this case, the first character in ``prefix_chars`` is used to prefix
588the 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
598The 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
635The following sections describe how each of these are used.
636
637
638name or flags
639^^^^^^^^^^^^^
640
641The :meth:`~ArgumentParser.add_argument` method must know whether an optional
642argument, like ``-f`` or ``--foo``, or a positional argument, like a list of
643filenames, is expected.  The first arguments passed to
644:meth:`~ArgumentParser.add_argument` must therefore be either a series of
645flags, or a simple argument name.  For example, an optional argument could
646be created like::
647
648   >>> parser.add_argument('-f', '--foo')
649
650while a positional argument could be created like::
651
652   >>> parser.add_argument('bar')
653
654When :meth:`~ArgumentParser.parse_args` is called, optional arguments will be
655identified by the ``-`` prefix, and the remaining arguments will be assumed to
656be 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
670action
671^^^^^^
672
673:class:`ArgumentParser` objects associate command-line arguments with actions.  These
674actions can do just about anything with the command-line arguments associated with
675them, though most actions simply add an attribute to the object returned by
676:meth:`~ArgumentParser.parse_args`.  The ``action`` keyword argument specifies
677how 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
752You may also specify an arbitrary action by passing an Action subclass or
753other object that implements the same interface.  The recommended way to do
754this is to extend :class:`Action`, overriding the ``__call__`` method
755and optionally the ``__init__`` method.
756
757An 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
777For more details, see :class:`Action`.
778
779nargs
780^^^^^
781
782ArgumentParser objects usually associate a single command-line argument with a
783single action to be taken.  The ``nargs`` keyword argument associates a
784different number of command-line arguments with a single action.  The supported
785values 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
866If the ``nargs`` keyword argument is not provided, the number of arguments consumed
867is determined by the action_.  Generally this means a single command-line argument
868will be consumed and a single item (not a list) will be produced.
869
870
871const
872^^^^^
873
874The ``const`` argument of :meth:`~ArgumentParser.add_argument` is used to hold
875constant values that are not read from the command line but are required for
876the 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
890With the ``'store_const'`` and ``'append_const'`` actions, the ``const``
891keyword argument must be given.  For other actions, it defaults to ``None``.
892
893
894default
895^^^^^^^
896
897All optional arguments and some positional arguments may be omitted at the
898command line.  The ``default`` keyword argument of
899:meth:`~ArgumentParser.add_argument`, whose value defaults to ``None``,
900specifies what value should be used if the command-line argument is not present.
901For optional arguments, the ``default`` value is used when the option string
902was 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
911If the ``default`` value is a string, the parser parses the value as if it
912were a command-line argument.  In particular, the parser applies any type_
913conversion 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
922For positional arguments with nargs_ equal to ``?`` or ``*``, the ``default`` value
923is 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
933Providing ``default=argparse.SUPPRESS`` causes no attribute to be added if the
934command-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
944type
945^^^^
946
947By default, :class:`ArgumentParser` objects read command-line arguments in as simple
948strings. However, quite often the command-line string should instead be
949interpreted as another type, like a :class:`float` or :class:`int`.  The
950``type`` keyword argument of :meth:`~ArgumentParser.add_argument` allows any
951necessary type-checking and type conversions to be performed.  Common built-in
952types 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
960See the section on the default_ keyword argument for information on when the
961``type`` argument is applied to default arguments.
962
963To ease the use of various types of files, the argparse module provides the
964factory FileType which takes the ``mode=`` and ``bufsize=`` arguments of the
965``file`` object.  For example, ``FileType('w')`` can be used to create a
966writable 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
974the 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
992The choices_ keyword argument may be more convenient for type checkers that
993simply 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
1003See the choices_ section for more details.
1004
1005
1006choices
1007^^^^^^^
1008
1009Some command-line arguments should be selected from a restricted set of values.
1010These can be handled by passing a container object as the *choices* keyword
1011argument to :meth:`~ArgumentParser.add_argument`.  When the command line is
1012parsed, argument values will be checked, and an error message will be displayed
1013if 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
1024Note that inclusion in the *choices* container is checked after any type_
1025conversions have been performed, so the type of the objects in the *choices*
1026container 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
1036Any object that supports the ``in`` operator can be passed as the *choices*
1037value, so :class:`dict` objects, :class:`set` objects, custom containers,
1038etc. are all supported.
1039
1040
1041required
1042^^^^^^^^
1043
1044In general, the :mod:`argparse` module assumes that flags like ``-f`` and ``--bar``
1045indicate *optional* arguments, which can always be omitted at the command line.
1046To make an option *required*, ``True`` can be specified for the ``required=``
1047keyword 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
1057As the example shows, if an option is marked as ``required``,
1058:meth:`~ArgumentParser.parse_args` will report an error if that option is not
1059present 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
1067help
1068^^^^
1069
1070The ``help`` value is a string containing a brief description of the argument.
1071When a user requests help (usually by using ``-h`` or ``--help`` at the
1072command line), these ``help`` descriptions will be displayed with each
1073argument::
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
1090The ``help`` strings can include various format specifiers to avoid repetition
1091of things like the program name or the argument default_.  The available
1092specifiers 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
1108setting 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
1119metavar
1120^^^^^^^
1121
1122When :class:`ArgumentParser` generates help messages, it needs some way to refer
1123to each expected argument.  By default, ArgumentParser objects use the dest_
1124value as the "name" of each object.  By default, for positional argument
1125actions, the dest_ value is used directly, and for optional argument actions,
1126the dest_ value is uppercased.  So, a single positional argument with
1127``dest='bar'`` will be referred to as ``bar``. A single
1128optional argument ``--foo`` that should be followed by a single command-line argument
1129will 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
1146An 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
1163Note that ``metavar`` only changes the *displayed* name - the name of the
1164attribute on the :meth:`~ArgumentParser.parse_args` object is still determined
1165by the dest_ value.
1166
1167Different values of ``nargs`` may cause the metavar to be used multiple times.
1168Providing a tuple to ``metavar`` specifies a different display for each of the
1169arguments::
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
1183dest
1184^^^^
1185
1186Most :class:`ArgumentParser` actions add some value as an attribute of the
1187object returned by :meth:`~ArgumentParser.parse_args`.  The name of this
1188attribute 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
1198For optional argument actions, the value of ``dest`` is normally inferred from
1199the option strings.  :class:`ArgumentParser` generates the value of ``dest`` by
1200taking the first long option string and stripping away the initial ``--``
1201string.  If no long option strings were supplied, ``dest`` will be derived from
1202the first short option string by stripping the initial ``-`` character.  Any
1203internal ``-`` characters will be converted to ``_`` characters to make sure
1204the string is a valid attribute name.  The examples below illustrate this
1205behavior::
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
1222Action classes
1223^^^^^^^^^^^^^^
1224
1225Action classes implement the Action API, a callable which returns a callable
1226which processes arguments from the command-line. Any object which follows this
1227API 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
1233Action objects are used by an ArgumentParser to represent the information needed
1234to parse a single argument from one or more strings from the command line. The
1235Action class must accept the two positional arguments plus any keyword arguments
1236passed to :meth:`ArgumentParser.add_argument` except for the ``action`` itself.
1237
1238Instances of Action (or return value of any callable to the ``action``
1239parameter) should have attributes "dest", "option_strings", "default", "type",
1240"required", "help", etc. defined. The easiest way to ensure these attributes
1241are defined is to call ``Action.__init__``.
1242
1243Action 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
1260The ``__call__`` method may perform arbitrary actions, but will typically set
1261attributes on the ``namespace`` based on ``dest`` and ``values``.
1262
1263
1264The 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
1280Option value syntax
1281^^^^^^^^^^^^^^^^^^^
1282
1283The :meth:`~ArgumentParser.parse_args` method supports several ways of
1284specifying the value of an option (if it takes one).  In the simplest case, the
1285option 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
1295For long options (options with names longer than a single character), the option
1296and value can also be passed as a single command-line argument, using ``=`` to
1297separate them::
1298
1299   >>> parser.parse_args(['--foo=FOO'])
1300   Namespace(foo='FOO', x=None)
1301
1302For short options (options only one character long), the option and its value
1303can be concatenated::
1304
1305   >>> parser.parse_args(['-xX'])
1306   Namespace(foo=None, x='X')
1307
1308Several short options can be joined together, using only a single ``-`` prefix,
1309as 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
1319Invalid arguments
1320^^^^^^^^^^^^^^^^^
1321
1322While parsing the command line, :meth:`~ArgumentParser.parse_args` checks for a
1323variety of errors, including ambiguous options, invalid types, invalid options,
1324wrong number of positional arguments, etc.  When it encounters such an error,
1325it 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
1347Arguments containing ``-``
1348^^^^^^^^^^^^^^^^^^^^^^^^^^
1349
1350The :meth:`~ArgumentParser.parse_args` method attempts to give errors whenever
1351the user has clearly made a mistake, but some situations are inherently
1352ambiguous.  For example, the command-line argument ``-1`` could either be an
1353attempt to specify an option or an attempt to provide a positional argument.
1354The :meth:`~ArgumentParser.parse_args` method is cautious here: positional
1355arguments may only begin with ``-`` if they look like negative numbers and
1356there 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
1388If you have positional arguments that must begin with ``-`` and don't look
1389like negative numbers, you can insert the pseudo-argument ``'--'`` which tells
1390:meth:`~ArgumentParser.parse_args` that everything after that is a positional
1391argument::
1392
1393   >>> parser.parse_args(['--', '-f'])
1394   Namespace(foo='-f', one=None)
1395
1396.. _prefix-matching:
1397
1398Argument abbreviations (prefix matching)
1399^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1400
1401The :meth:`~ArgumentParser.parse_args` method allows long options to be
1402abbreviated to a prefix, if the abbreviation is unambiguous (the prefix matches
1403a 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
1416An error is produced for arguments that could produce more than one options.
1417
1418
1419Beyond ``sys.argv``
1420^^^^^^^^^^^^^^^^^^^
1421
1422Sometimes it may be useful to have an ArgumentParser parse arguments other than those
1423of :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
1425interactive 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
1440The 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
1448This class is deliberately simple, just an :class:`object` subclass with a
1449readable string representation. If you prefer to have dict-like view of the
1450attributes, 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
1458It may also be useful to have an :class:`ArgumentParser` assign attributes to an
1459already existing object, rather than a new :class:`Namespace` object.  This can
1460be 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
1473Other utilities
1474---------------
1475
1476Sub-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
1663FileType 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
1688Argument 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
1740Mutual 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
1778Parser 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
1819Printing help
1820^^^^^^^^^^^^^
1821
1822In most typical applications, :meth:`~ArgumentParser.parse_args` will take
1823care of formatting and printing any usage or error messages.  However, several
1824formatting 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
1838There are also variants of these methods that simply return a string instead of
1839printing 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
1852Partial parsing
1853^^^^^^^^^^^^^^^
1854
1855.. method:: ArgumentParser.parse_known_args(args=None, namespace=None)
1856
1857Sometimes a script may only parse a few of the command-line arguments, passing
1858the 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
1861extra arguments are present.  Instead, it returns a two item tuple containing
1862the 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
1879Customizing 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
1900Exiting 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
1916Upgrading optparse code
1917-----------------------
1918
1919Originally, the :mod:`argparse` module had attempted to maintain compatibility
1920with :mod:`optparse`.  However, :mod:`optparse` was difficult to extend
1921transparently, 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
1924longer seemed practical to try to maintain the backwards compatibility.
1925
1926The :mod:`argparse` module improves on the standard library :mod:`optparse`
1927module 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
1936A 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