:mod:`optparse` --- More powerful command line option parser

============================================================

.. module:: optparse

   :synopsis: More convenient, flexible, and powerful command-line parsing library.

.. moduleauthor:: Greg Ward <gward@python.net>

.. versionadded:: 2.3

.. sectionauthor:: Greg Ward <gward@python.net>

``optparse`` is a more convenient, flexible, and powerful library for parsing

command-line options than the old :mod:`getopt` module.  ``optparse`` uses a more declarative

style of command-line parsing: you create an instance of :class:`OptionParser`,

populate it with options, and parse the command line. ``optparse`` allows users

to specify options in the conventional GNU/POSIX syntax, and additionally

generates usage and help messages for you.

Here's an example of using ``optparse`` in a simple script::

   from optparse import OptionParser

   [...]

   parser = OptionParser()

   parser.add_option("-f", "--file", dest="filename",

                     help="write report to FILE", metavar="FILE")

   parser.add_option("-q", "--quiet",

                     action="store_false", dest="verbose", default=True,

                     help="don't print status messages to stdout")

   (options, args) = parser.parse_args()

With these few lines of code, users of your script can now do the "usual thing"

on the command-line, for example::

   <yourscript> --file=outfile -q

As it parses the command line, ``optparse`` sets attributes of the ``options``

object returned by :meth:`parse_args` based on user-supplied command-line

values.  When :meth:`parse_args` returns from parsing this command line,

``options.filename`` will be ``"outfile"`` and ``options.verbose`` will be

``False``.  ``optparse`` supports both long and short options, allows short

options to be merged together, and allows options to be associated with their

arguments in a variety of ways.  Thus, the following command lines are all

equivalent to the above example::

   <yourscript> -f outfile --quiet

   <yourscript> --quiet --file outfile

   <yourscript> -q -foutfile

   <yourscript> -qfoutfile

Additionally, users can run one of  ::

   <yourscript> -h

   <yourscript> --help

and ``optparse`` will print out a brief summary of your script's options::

   usage: <yourscript> [options]

   options:

     -h, --help            show this help message and exit

     -f FILE, --file=FILE  write report to FILE

     -q, --quiet           don't print status messages to stdout

where the value of *yourscript* is determined at runtime (normally from

``sys.argv[0]``).

.. _optparse-background:

Background

----------

:mod:`optparse` was explicitly designed to encourage the creation of programs

with straightforward, conventional command-line interfaces.  To that end, it

supports only the most common command-line syntax and semantics conventionally

used under Unix.  If you are unfamiliar with these conventions, read this

section to acquaint yourself with them.

.. _optparse-terminology:

Terminology

^^^^^^^^^^^

argument

   a string entered on the command-line, and passed by the shell to ``execl()`` or

   ``execv()``.  In Python, arguments are elements of ``sys.argv[1:]``

   (``sys.argv[0]`` is the name of the program being executed).  Unix shells also

   use the term "word".

   It is occasionally desirable to substitute an argument list other than

   ``sys.argv[1:]``, so you should read "argument" as "an element of

   ``sys.argv[1:]``, or of some other list provided as a substitute for

   ``sys.argv[1:]``".

option

   an argument used to supply extra information to guide or customize the execution

   of a program.  There are many different syntaxes for options; the traditional

   Unix syntax is a hyphen ("-") followed by a single letter, e.g. ``"-x"`` or

   ``"-F"``.  Also, traditional Unix syntax allows multiple options to be merged

   into a single argument, e.g.  ``"-x -F"`` is equivalent to ``"-xF"``.  The GNU

   project introduced ``"--"`` followed by a series of hyphen-separated words, e.g.

   ``"--file"`` or ``"--dry-run"``.  These are the only two option syntaxes

   provided by :mod:`optparse`.

   Some other option syntaxes that the world has seen include:

   * a hyphen followed by a few letters, e.g. ``"-pf"`` (this is *not* the same

     as multiple options merged into a single argument)

   * a hyphen followed by a whole word, e.g. ``"-file"`` (this is technically

     equivalent to the previous syntax, but they aren't usually seen in the same

     program)

   * a plus sign followed by a single letter, or a few letters, or a word, e.g.

     ``"+f"``, ``"+rgb"``

   * a slash followed by a letter, or a few letters, or a word, e.g. ``"/f"``,

     ``"/file"``

   These option syntaxes are not supported by :mod:`optparse`, and they never will

   be.  This is deliberate: the first three are non-standard on any environment,

   and the last only makes sense if you're exclusively targeting VMS, MS-DOS,

   and/or Windows.

option argument

   an argument that follows an option, is closely associated with that option, and

   is consumed from the argument list when that option is. With :mod:`optparse`,

   option arguments may either be in a separate argument from their option::

      -f foo

      --file foo

   or included in the same argument::

      -ffoo

      --file=foo

   Typically, a given option either takes an argument or it doesn't. Lots of people

   want an "optional option arguments" feature, meaning that some options will take

   an argument if they see it, and won't if they don't.  This is somewhat

   controversial, because it makes parsing ambiguous: if ``"-a"`` takes an optional

   argument and ``"-b"`` is another option entirely, how do we interpret ``"-ab"``?

   Because of this ambiguity, :mod:`optparse` does not support this feature.

positional argument

   something leftover in the argument list after options have been parsed, i.e.

   after options and their arguments have been parsed and removed from the argument

   list.

required option

   an option that must be supplied on the command-line; note that the phrase

   "required option" is self-contradictory in English.  :mod:`optparse` doesn't

   prevent you from implementing required options, but doesn't give you much help

   at it either.  See ``examples/required_1.py`` and ``examples/required_2.py`` in

   the :mod:`optparse` source distribution for two ways to implement required

   options with :mod:`optparse`.

For example, consider this hypothetical command-line::

   prog -v --report /tmp/report.txt foo bar

``"-v"`` and ``"--report"`` are both options.  Assuming that :option:`--report`

takes one argument, ``"/tmp/report.txt"`` is an option argument.  ``"foo"`` and

``"bar"`` are positional arguments.

.. _optparse-what-options-for:

What are options for?

^^^^^^^^^^^^^^^^^^^^^

Options are used to provide extra information to tune or customize the execution

of a program.  In case it wasn't clear, options are usually *optional*.  A

program should be able to run just fine with no options whatsoever.  (Pick a

random program from the Unix or GNU toolsets.  Can it run without any options at

all and still make sense?  The main exceptions are ``find``, ``tar``, and

``dd``\ ---all of which are mutant oddballs that have been rightly criticized

for their non-standard syntax and confusing interfaces.)

Lots of people want their programs to have "required options".  Think about it.

If it's required, then it's *not optional*!  If there is a piece of information

that your program absolutely requires in order to run successfully, that's what

positional arguments are for.

As an example of good command-line interface design, consider the humble ``cp``

utility, for copying files.  It doesn't make much sense to try to copy files

without supplying a destination and at least one source. Hence, ``cp`` fails if

you run it with no arguments.  However, it has a flexible, useful syntax that

does not require any options at all::

   cp SOURCE DEST

   cp SOURCE ... DEST-DIR

You can get pretty far with just that.  Most ``cp`` implementations provide a

bunch of options to tweak exactly how the files are copied: you can preserve

mode and modification time, avoid following symlinks, ask before clobbering

existing files, etc.  But none of this distracts from the core mission of

``cp``, which is to copy either one file to another, or several files to another

directory.

.. _optparse-what-positional-arguments-for:

What are positional arguments for?

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Positional arguments are for those pieces of information that your program

absolutely, positively requires to run.

A good user interface should have as few absolute requirements as possible.  If

your program requires 17 distinct pieces of information in order to run

successfully, it doesn't much matter *how* you get that information from the

user---most people will give up and walk away before they successfully run the

program.  This applies whether the user interface is a command-line, a

configuration file, or a GUI: if you make that many demands on your users, most

of them will simply give up.

In short, try to minimize the amount of information that users are absolutely

required to supply---use sensible defaults whenever possible.  Of course, you

also want to make your programs reasonably flexible.  That's what options are

for.  Again, it doesn't matter if they are entries in a config file, widgets in

the "Preferences" dialog of a GUI, or command-line options---the more options

you implement, the more flexible your program is, and the more complicated its

implementation becomes.  Too much flexibility has drawbacks as well, of course;

too many options can overwhelm users and make your code much harder to maintain.

.. _optparse-tutorial:

Tutorial

--------

While :mod:`optparse` is quite flexible and powerful, it's also straightforward

to use in most cases.  This section covers the code patterns that are common to

any :mod:`optparse`\ -based program.

First, you need to import the OptionParser class; then, early in the main

program, create an OptionParser instance::

   from optparse import OptionParser

   [...]

   parser = OptionParser()

Then you can start defining options.  The basic syntax is::

   parser.add_option(opt_str, ...,

                     attr=value, ...)

Each option has one or more option strings, such as ``"-f"`` or ``"--file"``,

and several option attributes that tell :mod:`optparse` what to expect and what

to do when it encounters that option on the command line.

Typically, each option will have one short option string and one long option

string, e.g.::

   parser.add_option("-f", "--file", ...)

You're free to define as many short option strings and as many long option

strings as you like (including zero), as long as there is at least one option

string overall.

The option strings passed to :meth:`add_option` are effectively labels for the

option defined by that call.  For brevity, we will frequently refer to

*encountering an option* on the command line; in reality, :mod:`optparse`

encounters *option strings* and looks up options from them.

Once all of your options are defined, instruct :mod:`optparse` to parse your

program's command line::

   (options, args) = parser.parse_args()

(If you like, you can pass a custom argument list to :meth:`parse_args`, but

that's rarely necessary: by default it uses ``sys.argv[1:]``.)

:meth:`parse_args` returns two values:

* ``options``, an object containing values for all of your options---e.g. if

  ``"--file"`` takes a single string argument, then ``options.file`` will be the

  filename supplied by the user, or ``None`` if the user did not supply that

  option

* ``args``, the list of positional arguments leftover after parsing options

This tutorial section only covers the four most important option attributes:

:attr:`action`, :attr:`type`, :attr:`dest` (destination), and :attr:`help`. Of

these, :attr:`action` is the most fundamental.

.. _optparse-understanding-option-actions:

Understanding option actions

^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Actions tell :mod:`optparse` what to do when it encounters an option on the

command line.  There is a fixed set of actions hard-coded into :mod:`optparse`;

adding new actions is an advanced topic covered in section

:ref:`optparse-extending-optparse`. Most actions tell

:mod:`optparse` to store a value in some variable---for example, take a string

from the command line and store it in an attribute of ``options``.

If you don't specify an option action, :mod:`optparse` defaults to ``store``.

.. _optparse-store-action:

The store action

^^^^^^^^^^^^^^^^

The most common option action is ``store``, which tells :mod:`optparse` to take

the next argument (or the remainder of the current argument), ensure that it is

of the correct type, and store it to your chosen destination.

For example::

   parser.add_option("-f", "--file",

                     action="store", type="string", dest="filename")

Now let's make up a fake command line and ask :mod:`optparse` to parse it::

   args = ["-f", "foo.txt"]

   (options, args) = parser.parse_args(args)

When :mod:`optparse` sees the option string ``"-f"``, it consumes the next

argument, ``"foo.txt"``, and stores it in ``options.filename``.  So, after this

call to :meth:`parse_args`, ``options.filename`` is ``"foo.txt"``.

Some other option types supported by :mod:`optparse` are ``int`` and ``float``.

Here's an option that expects an integer argument::

   parser.add_option("-n", type="int", dest="num")

Note that this option has no long option string, which is perfectly acceptable.

Also, there's no explicit action, since the default is ``store``.

Let's parse another fake command-line.  This time, we'll jam the option argument

right up against the option: since ``"-n42"`` (one argument) is equivalent to

``"-n 42"`` (two arguments), the code  ::

   (options, args) = parser.parse_args(["-n42"])

   print options.num

will print ``"42"``.

If you don't specify a type, :mod:`optparse` assumes ``string``.  Combined with

the fact that the default action is ``store``, that means our first example can

be a lot shorter::

   parser.add_option("-f", "--file", dest="filename")

If you don't supply a destination, :mod:`optparse` figures out a sensible

default from the option strings: if the first long option string is

``"--foo-bar"``, then the default destination is ``foo_bar``.  If there are no

long option strings, :mod:`optparse` looks at the first short option string: the

default destination for ``"-f"`` is ``f``.

:mod:`optparse` also includes built-in ``long`` and ``complex`` types.  Adding

types is covered in section :ref:`optparse-extending-optparse`.

.. _optparse-handling-boolean-options:

Handling boolean (flag) options

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Flag options---set a variable to true or false when a particular option is seen

---are quite common.  :mod:`optparse` supports them with two separate actions,

``store_true`` and ``store_false``.  For example, you might have a ``verbose``

flag that is turned on with ``"-v"`` and off with ``"-q"``::

   parser.add_option("-v", action="store_true", dest="verbose")

   parser.add_option("-q", action="store_false", dest="verbose")

Here we have two different options with the same destination, which is perfectly

OK.  (It just means you have to be a bit careful when setting default values---

see below.)

When :mod:`optparse` encounters ``"-v"`` on the command line, it sets

``options.verbose`` to ``True``; when it encounters ``"-q"``,

``options.verbose`` is set to ``False``.

.. _optparse-other-actions:

Other actions

^^^^^^^^^^^^^

Some other actions supported by :mod:`optparse` are:

``store_const``

   store a constant value

``append``

   append this option's argument to a list

``count``

   increment a counter by one

``callback``

   call a specified function

These are covered in section :ref:`optparse-reference-guide`, Reference Guide

and section :ref:`optparse-option-callbacks`.

.. _optparse-default-values:

Default values

^^^^^^^^^^^^^^

All of the above examples involve setting some variable (the "destination") when

certain command-line options are seen.  What happens if those options are never

seen?  Since we didn't supply any defaults, they are all set to ``None``.  This

is usually fine, but sometimes you want more control.  :mod:`optparse` lets you

supply a default value for each destination, which is assigned before the

command line is parsed.

First, consider the verbose/quiet example.  If we want :mod:`optparse` to set

``verbose`` to ``True`` unless ``"-q"`` is seen, then we can do this::

   parser.add_option("-v", action="store_true", dest="verbose", default=True)

   parser.add_option("-q", action="store_false", dest="verbose")

Since default values apply to the *destination* rather than to any particular

option, and these two options happen to have the same destination, this is

exactly equivalent::

   parser.add_option("-v", action="store_true", dest="verbose")

   parser.add_option("-q", action="store_false", dest="verbose", default=True)

Consider this::

   parser.add_option("-v", action="store_true", dest="verbose", default=False)

   parser.add_option("-q", action="store_false", dest="verbose", default=True)

Again, the default value for ``verbose`` will be ``True``: the last default

value supplied for any particular destination is the one that counts.

A clearer way to specify default values is the :meth:`set_defaults` method of

OptionParser, which you can call at any time before calling :meth:`parse_args`::

   parser.set_defaults(verbose=True)

   parser.add_option(...)

   (options, args) = parser.parse_args()

As before, the last value specified for a given option destination is the one

that counts.  For clarity, try to use one method or the other of setting default

values, not both.

.. _optparse-generating-help:

Generating help

^^^^^^^^^^^^^^^

:mod:`optparse`'s ability to generate help and usage text automatically is

useful for creating user-friendly command-line interfaces.  All you have to do

is supply a :attr:`help` value for each option, and optionally a short usage

message for your whole program.  Here's an OptionParser populated with

user-friendly (documented) options::

   usage = "usage: %prog [options] arg1 arg2"

   parser = OptionParser(usage=usage)

   parser.add_option("-v", "--verbose",

                     action="store_true", dest="verbose", default=True,

                     help="make lots of noise [default]")

   parser.add_option("-q", "--quiet",

                     action="store_false", dest="verbose",

                     help="be vewwy quiet (I'm hunting wabbits)")

   parser.add_option("-f", "--filename",

                     metavar="FILE", help="write output to FILE"),

   parser.add_option("-m", "--mode",

                     default="intermediate",

                     help="interaction mode: novice, intermediate, "

                          "or expert [default: %default]")

If :mod:`optparse` encounters either ``"-h"`` or ``"--help"`` on the

command-line, or if you just call :meth:`parser.print_help`, it prints the

following to standard output::

   usage: <yourscript> [options] arg1 arg2

   options:

     -h, --help            show this help message and exit

     -v, --verbose         make lots of noise [default]

     -q, --quiet           be vewwy quiet (I'm hunting wabbits)

     -f FILE, --filename=FILE

                           write output to FILE

     -m MODE, --mode=MODE  interaction mode: novice, intermediate, or

                           expert [default: intermediate]

(If the help output is triggered by a help option, :mod:`optparse` exits after

printing the help text.)

There's a lot going on here to help :mod:`optparse` generate the best possible

help message:

* the script defines its own usage message::

     usage = "usage: %prog [options] arg1 arg2"

  :mod:`optparse` expands ``"%prog"`` in the usage string to the name of the

  current program, i.e. ``os.path.basename(sys.argv[0])``.  The expanded string is

  then printed before the detailed option help.

  If you don't supply a usage string, :mod:`optparse` uses a bland but sensible

  default: ``"usage: %prog [options]"``, which is fine if your script doesn't take

  any positional arguments.

* every option defines a help string, and doesn't worry about line-wrapping---

  :mod:`optparse` takes care of wrapping lines and making the help output look

  good.

* options that take a value indicate this fact in their automatically-generated

  help message, e.g. for the "mode" option::

     -m MODE, --mode=MODE

  Here, "MODE" is called the meta-variable: it stands for the argument that the

  user is expected to supply to :option:`-m`/:option:`--mode`.  By default,

  :mod:`optparse` converts the destination variable name to uppercase and uses

  that for the meta-variable.  Sometimes, that's not what you want---for example,

  the :option:`--filename` option explicitly sets ``metavar="FILE"``, resulting in

  this automatically-generated option description::

     -f FILE, --filename=FILE