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