|
3 | 3 |
|
4 | 4 | .. module:: optparse
|
5 | 5 | :synopsis: Command-line option parsing library.
|
6 |
| - :deprecated: |
7 | 6 |
|
8 | 7 | .. moduleauthor:: Greg Ward <[email protected]>
|
9 | 8 | .. sectionauthor:: Greg Ward <[email protected]>
|
10 | 9 |
|
11 | 10 | **Source code:** :source:`Lib/optparse.py`
|
12 | 11 |
|
13 |
| -.. deprecated:: 3.2 |
14 |
| - The :mod:`optparse` module is :term:`soft deprecated` and will not be |
15 |
| - developed further; development will continue with the :mod:`argparse` |
16 |
| - module. |
17 |
| - |
18 | 12 | --------------
|
19 | 13 |
|
| 14 | +.. _choosing-an-argument-parser: |
| 15 | + |
| 16 | +Choosing an argument parsing library |
| 17 | +------------------------------------ |
| 18 | + |
| 19 | +The standard library includes three argument parsing libraries: |
| 20 | + |
| 21 | +* :mod:`getopt`: a module that closely mirrors the procedural C ``getopt`` API. |
| 22 | + Included in the standard library since before the initial Python 1.0 release. |
| 23 | +* :mod:`optparse`: a declarative replacement for ``getopt`` that |
| 24 | + provides equivalent functionality without requiring each application |
| 25 | + to implement its own procedural option parsing logic. Included |
| 26 | + in the standard library since the Python 2.3 release. |
| 27 | +* :mod:`argparse`: a more opinionated alternative to ``optparse`` that |
| 28 | + provides more functionality by default, at the expense of reduced application |
| 29 | + flexibility in controlling exactly how arguments are processed. Included in |
| 30 | + the standard library since the Python 2.7 and Python 3.2 releases. |
| 31 | + |
| 32 | +In the absence of more specific argument parsing design constraints, :mod:`argparse` |
| 33 | +is the recommended choice for implementing command line applications, as it offers |
| 34 | +the highest level of baseline functionality with the least application level code. |
| 35 | + |
| 36 | +:mod:`getopt` is retained almost entirely for backwards compatibility reasons. |
| 37 | +However, it also serves a niche use case as a tool for prototyping and testing |
| 38 | +command line argument handling in ``getopt``-based C applications. |
| 39 | + |
| 40 | +:mod:`optparse` should be considered as an alternative to :mod:`argparse` in the |
| 41 | +following cases: |
| 42 | + |
| 43 | +* an application is already using :mod:`optparse` and doesn't want to risk the |
| 44 | + subtle behavioural changes that may arise when migrating to :mod:`argparse` |
| 45 | +* the application requires additional control over the way options and |
| 46 | + positional parameters are interleaved on the command line (including |
| 47 | + the ability to disable the interleaving feature completely) |
| 48 | +* the application requires additional control over the incremental parsing |
| 49 | + of command line elements (while ``argparse`` does support this, the |
| 50 | + exact way it works in practice is undesirable for some use cases) |
| 51 | +* the application requires additional control over the handling of options |
| 52 | + which accept parameter values that may start with ``-`` (such as delegated |
| 53 | + options to be passed to invoked subprocesses) |
| 54 | +* the application requires some other command line parameter processing |
| 55 | + behavior which ``argparse`` does not support, but which can be implemented |
| 56 | + in terms of the lower level interface offered by ``optparse`` |
| 57 | + |
| 58 | +These considerations also mean that :mod:`optparse` is likely to provide a |
| 59 | +better foundation for library authors writing third party command line |
| 60 | +argument processing libraries. |
| 61 | + |
| 62 | +As a concrete example, consider the following two command line argument |
| 63 | +parsing configurations, the first using ``optparse``, and the second |
| 64 | +using ``argparse``: |
| 65 | + |
| 66 | +.. testcode:: |
| 67 | + |
| 68 | + import optparse |
| 69 | + |
| 70 | + if __name__ == '__main__': |
| 71 | + parser = optparse.OptionParser() |
| 72 | + parser.add_option('-o', '--output') |
| 73 | + parser.add_option('-v', dest='verbose', action='store_true') |
| 74 | + opts, args = parser.parse_args() |
| 75 | + process(args, output=opts.output, verbose=opts.verbose) |
| 76 | + |
| 77 | +.. testcode:: |
| 78 | + |
| 79 | + import argparse |
| 80 | + |
| 81 | + if __name__ == '__main__': |
| 82 | + parser = argparse.ArgumentParser() |
| 83 | + parser.add_argument('-o', '--output') |
| 84 | + parser.add_argument('-v', dest='verbose', action='store_true') |
| 85 | + parser.add_argument('rest', nargs='*') |
| 86 | + args = parser.parse_args() |
| 87 | + process(args.rest, output=args.output, verbose=args.verbose) |
| 88 | + |
| 89 | +The most obvious difference is that in the ``optparse`` version, the non-option |
| 90 | +arguments are processed separately by the application after the option processing |
| 91 | +is complete. In the ``argparse`` version, positional arguments are declared and |
| 92 | +processed in the same way as the named options. |
| 93 | + |
| 94 | +However, the ``argparse`` version will also handle some parameter combination |
| 95 | +differently from the way the ``optparse`` version would handle them. |
| 96 | +For example (amongst other differences): |
| 97 | + |
| 98 | +* supplying ``-o -v`` gives ``output="-v"`` and ``verbose=False`` |
| 99 | + when using ``optparse``, but a usage error with ``argparse`` |
| 100 | + (complaining that no value has been supplied for ``-o/--output``, |
| 101 | + since ``-v`` is interpreted as meaning the verbosity flag) |
| 102 | +* similarly, supplying ``-o --`` gives ``output="--"`` and ``args=()`` |
| 103 | + when using ``optparse``, but a usage error with ``argparse`` |
| 104 | + (also complaining that no value has been supplied for ``-o/--output``, |
| 105 | + since ``--`` is interpreted as terminating the option processing |
| 106 | + and treating all remaining values as positional arguments) |
| 107 | +* supplying ``-o=foo`` gives ``output="=foo"`` when using ``optparse``, |
| 108 | + but gives ``output="foo"`` with ``argparse`` (since ``=`` is special |
| 109 | + cased as an alternative separator for option parameter values) |
| 110 | + |
| 111 | +Whether these differing behaviors in the ``argparse`` version are |
| 112 | +considered desirable or a problem will depend on the specific command line |
| 113 | +application use case. |
| 114 | + |
| 115 | +.. seealso:: |
| 116 | + |
| 117 | + :pypi:`click` is a third party argument processing library (originally |
| 118 | + based on ``optparse``), which allows command line applications to be |
| 119 | + developed as a set of decorated command implementation functions. |
| 120 | + |
| 121 | + Other third party libraries, such as :pypi:`typer` or :pypi:`msgspec-click`, |
| 122 | + allow command line interfaces to be specified in ways that more effectively |
| 123 | + integrate with static checking of Python type annotations. |
| 124 | + |
| 125 | + |
| 126 | +Introduction |
| 127 | +------------ |
| 128 | + |
20 | 129 | :mod:`optparse` is a more convenient, flexible, and powerful library for parsing
|
21 |
| -command-line options than the old :mod:`getopt` module. :mod:`optparse` uses a |
22 |
| -more declarative style of command-line parsing: you create an instance of |
23 |
| -:class:`OptionParser`, populate it with options, and parse the command |
24 |
| -line. :mod:`optparse` allows users to specify options in the conventional |
| 130 | +command-line options than the minimalist :mod:`getopt` module. |
| 131 | +:mod:`optparse` uses a more declarative style of command-line parsing: |
| 132 | +you create an instance of :class:`OptionParser`, |
| 133 | +populate it with options, and parse the command line. |
| 134 | +:mod:`optparse` allows users to specify options in the conventional |
25 | 135 | GNU/POSIX syntax, and additionally generates usage and help messages for you.
|
26 | 136 |
|
27 | 137 | Here's an example of using :mod:`optparse` in a simple script::
|
@@ -82,10 +192,11 @@ Background
|
82 | 192 | ----------
|
83 | 193 |
|
84 | 194 | :mod:`optparse` was explicitly designed to encourage the creation of programs
|
85 |
| -with straightforward, conventional command-line interfaces. To that end, it |
86 |
| -supports only the most common command-line syntax and semantics conventionally |
87 |
| -used under Unix. If you are unfamiliar with these conventions, read this |
88 |
| -section to acquaint yourself with them. |
| 195 | +with straightforward command-line interfaces that follow the conventions |
| 196 | +established by the :c:func:`!getopt` family of functions available to C developers. |
| 197 | +To that end, it supports only the most common command-line syntax and semantics |
| 198 | +conventionally used under Unix. If you are unfamiliar with these conventions, |
| 199 | +reading this section will allow you to acquaint yourself with them. |
89 | 200 |
|
90 | 201 |
|
91 | 202 | .. _optparse-terminology:
|
|
0 commit comments