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