[Python-checkins] python/dist/src/Doc/lib liboptparse.tex,1.1,1.2
fdrake@users.sourceforge.net
fdrake@users.sourceforge.net
Fri, 18 Apr 2003 08:50:15 -0700
Update of /cvsroot/python/python/dist/src/Doc/lib
In directory sc8-pr-cvs1:/tmp/cvs-serv19720
Modified Files:
liboptparse.tex
Log Message:
- accepted (slightly) modified version of docs for the OptionGroup
class; closes SF patch #697941
- use em-dashes intead of en-dashes
- section references: use a "tie" between the word "section" and the
section number, use quotation marks around section titles
- other minor markup corrections/cleanups
Index: liboptparse.tex
===================================================================
RCS file: /cvsroot/python/python/dist/src/Doc/lib/liboptparse.tex,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** liboptparse.tex 6 Jan 2003 16:51:35 -0000 1.1
--- liboptparse.tex 18 Apr 2003 15:50:13 -0000 1.2
***************
*** 22,26 ****
\begin{verbatim}
from optparse import OptionParser
! [...]
parser = OptionParser()
parser.add_option("-f", "--file", dest="filename",
--- 22,26 ----
\begin{verbatim}
from optparse import OptionParser
!
parser = OptionParser()
parser.add_option("-f", "--file", dest="filename",
***************
*** 74,78 ****
argument parsing, and \module{optparse} reflects many of those ideas.
This section is meant to explain this philosophy, which in turn is
! heavily influenced by the Unix and GNU toolkits.
\subsubsection{Terminology\label{optparse-terminology}}
--- 74,78 ----
argument parsing, and \module{optparse} reflects many of those ideas.
This section is meant to explain this philosophy, which in turn is
! heavily influenced by the \UNIX{} and GNU toolkits.
\subsubsection{Terminology\label{optparse-terminology}}
***************
*** 87,91 ****
\var{sys.argv[1:]}. (\var{sys.argv[0]} is the name of the program
being executed; in the context of parsing arguments, it's not very
! important.) Unix shells also use the term ``word''.
It's occasionally desirable to substitute an argument list other
--- 87,91 ----
\var{sys.argv[1:]}. (\var{sys.argv[0]} is the name of the program
being executed; in the context of parsing arguments, it's not very
! important.) \UNIX{} shells also use the term ``word''.
It's occasionally desirable to substitute an argument list other
***************
*** 97,103 ****
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 \programopt{-} followed by a
single letter, e.g. \programopt{-x} or \programopt{-F}. Also,
! traditional Unix syntax allows multiple options to be merged into a
single argument, e.g. \programopt{-x -F} is equivalent to
\programopt{-xF}. The GNU project introduced \longprogramopt{}
--- 97,103 ----
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 \programopt{-} followed by a
single letter, e.g. \programopt{-x} or \programopt{-F}. Also,
! traditional \UNIX{} syntax allows multiple options to be merged into a
single argument, e.g. \programopt{-x -F} is equivalent to
\programopt{-xF}. The GNU project introduced \longprogramopt{}
***************
*** 125,129 ****
syntaxes, you'll have to subclass OptionParser and override all the
difficult bits. But please don't! \module{optparse} does things the
! traditional Unix/GNU way deliberately; the first three are
non-standard anywhere, and the last one makes sense only if you're
exclusively targeting MS-DOS/Windows and/or VMS.)
--- 125,129 ----
syntaxes, you'll have to subclass OptionParser and override all the
difficult bits. But please don't! \module{optparse} does things the
! traditional \UNIX/GNU way deliberately; the first three are
non-standard anywhere, and the last one makes sense only if you're
exclusively targeting MS-DOS/Windows and/or VMS.)
***************
*** 162,170 ****
\term{required option}
an option that must be supplied on the command-line; the phrase
! "required option" is an oxymoron and I personally consider it poor UI
design. \module{optparse} doesn't prevent you from implementing
! required options, but doesn't give you much help at it either. See
! Extending Examples (section \ref{optparse-extending-examples}) for two
! ways to implement required options with \module{optparse}.
\end{definitions}
--- 162,170 ----
\term{required option}
an option that must be supplied on the command-line; the phrase
! ``required option'' is an oxymoron and is usually considered poor UI
design. \module{optparse} doesn't prevent you from implementing
! required options, but doesn't give you much help with it either. See
! ``Extending Examples'' (section~\ref{optparse-extending-examples}) for
! two ways to implement required options with \module{optparse}.
\end{definitions}
***************
*** 186,194 ****
execution of a program. In case it wasn't clear, options are usually
\emph{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 only exceptions I can think of 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''.
--- 186,195 ----
execution of a program. In case it wasn't clear, options are usually
\emph{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 only exceptions I can think of are \program{find}, \program{tar},
! and \program{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''.
***************
*** 197,203 ****
in order to run successfully, that's what positional arguments are
for. (However, if you insist on adding ``required options'' to your
! programs, look in Extending Examples (section
! \ref{optparse-extending-examples}) for two ways of implementing them
! with \module{optparse}.)
Consider the humble \program{cp} utility, for copying files. It
--- 198,204 ----
in order to run successfully, that's what positional arguments are
for. (However, if you insist on adding ``required options'' to your
! programs, look in ``Extending Examples''
! (section~\ref{optparse-extending-examples}) for two ways of
! implementing them with \module{optparse}.)
Consider the humble \program{cp} utility, for copying files. It
***************
*** 228,232 ****
possible. If your program requires 17 distinct pieces of information in
order to run successfully, it doesn't much matter \emph{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, a GUI, or whatever:
--- 229,233 ----
possible. If your program requires 17 distinct pieces of information in
order to run successfully, it doesn't much matter \emph{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, a GUI, or whatever:
***************
*** 235,243 ****
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, checkboxes 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. It's quite easy to overwhelm users (and
--- 236,244 ----
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, checkboxes 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. It's quite easy to overwhelm users (and
***************
*** 269,273 ****
Then you can start populating the parser with options. Each option is
really a set of synonymous option strings; most commonly, you'll have
! one short option string and one long option string --
e.g. \programopt{-f} and \longprogramopt{file}:
--- 270,274 ----
Then you can start populating the parser with options. Each option is
really a set of synonymous option strings; most commonly, you'll have
! one short option string and one long option string ---
e.g. \programopt{-f} and \longprogramopt{file}:
***************
*** 308,314 ****
When \module{optparse} sees the \programopt{-f}, it sucks in the next
! argument -- ``foo.txt'' -- and stores it in the \var{filename}
attribute of a special object. That object is the first return value
! from \programopt{parse_args()}, so:
\begin{verbatim}
--- 309,315 ----
When \module{optparse} sees the \programopt{-f}, it sucks in the next
! argument --- ``foo.txt'' --- and stores it in the \var{filename}
attribute of a special object. That object is the first return value
! from \function{parse_args()}, so:
\begin{verbatim}
***************
*** 326,333 ****
Note that I didn't supply a long option, which is perfectly acceptable.
! I also didn't specify the action -- it defaults to ``store''.
Let's parse another fake command-line. This time, we'll jam the
! option argument right up against the option -- \programopt{-n42} (one
argument) is equivalent to \programopt{-n 42} (two arguments). :
--- 327,334 ----
Note that I didn't supply a long option, which is perfectly acceptable.
! I also didn't specify the action --- it defaults to ``store''.
Let's parse another fake command-line. This time, we'll jam the
! option argument right up against the option --- \programopt{-n42} (one
argument) is equivalent to \programopt{-n 42} (two arguments). :
***************
*** 356,366 ****
destination for \programopt{-f} is \var{f}.
! Adding types is fairly easy; please refer to section
! \ref{optparse-adding-types}: Adding new types.
\subsubsection{Other "store_*" actions\label{optparse-other-store-actions}}
! Flag options -- set a variable to true or false when a particular
! option is seen -- are quite common. \module{optparse} supports them
with two separate actions, ``store_true'' and ``store_false''. For
example, you might have a \var{verbose} flag that is turned on with
--- 357,367 ----
destination for \programopt{-f} is \var{f}.
! Adding types is fairly easy; please refer to
! section~\ref{optparse-adding-types}, ``Adding new types.''
\subsubsection{Other "store_*" actions\label{optparse-other-store-actions}}
! Flag options --- set a variable to true or false when a particular
! option is seen --- are quite common. \module{optparse} supports them
with two separate actions, ``store_true'' and ``store_false''. For
example, you might have a \var{verbose} flag that is turned on with
***************
*** 374,378 ****
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 \module{optparse} sees \programopt{-v} on the command line, it
--- 375,379 ----
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 \module{optparse} sees \programopt{-v} on the command line, it
***************
*** 393,398 ****
First, consider the verbose/quiet example. If we want
! \module{optparse} to set \var{verbose} to 1 unless -q is seen, then
! we can do this:
\begin{verbatim}
--- 394,399 ----
First, consider the verbose/quiet example. If we want
! \module{optparse} to set \var{verbose} to 1 unless \programopt{-q} is
! seen, then we can do this:
\begin{verbatim}
***************
*** 483,487 ****
\item every option defines a help string, and doesn't worry about
! line-wrapping -- \module{optparse} takes care of wrapping lines and
making the help output look good.
--- 484,488 ----
\item every option defines a help string, and doesn't worry about
! line-wrapping --- \module{optparse} takes care of wrapping lines and
making the help output look good.
***************
*** 497,501 ****
\programopt{-m}/\longprogramopt{mode}. By default, \module{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 \var{filename} option explicitly sets
\code{metavar="FILE"}, resulting in this automatically-generated
--- 498,502 ----
\programopt{-m}/\longprogramopt{mode}. By default, \module{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 \var{filename} option explicitly sets
\code{metavar="FILE"}, resulting in this automatically-generated
***************
*** 514,517 ****
--- 515,553 ----
\end{itemize}
+ When dealing with many options, it is convenient to group these
+ options for better help output. An \class{OptionParser} can contain
+ several option groups, each of which can contain several options.
+
+ Continuing with the parser defined above, adding an
+ \class{OptionGroup} to a parser is easy:
+
+ \begin{verbatim}
+ group = OptionGroup(parser, "Dangerous Options",
+ "Caution: use these options at your own risk."
+ " It is believed that some of them bite.")
+ group.add_option("-g", action="store_true", help="Group option.")
+ parser.add_option_group(group)
+ \end{verbatim}
+
+ This would result in the following help output:
+
+ \begin{verbatim}
+ usage: [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)
+ -fFILE, --file=FILE write output to FILE
+ -mMODE, --mode=MODE interaction mode: one of 'novice', 'intermediate'
+ [default], 'expert'
+
+ Dangerous Options:
+ Caution: use of these options is at your own risk. It is believed that
+ some of them bite.
+ -g Group option.
+ \end{verbatim}
+
+
\subsubsection{Print a version number\label{optparse-print-version}}
***************
*** 543,547 ****
The one thing you need to know for basic usage is how
\module{optparse} behaves when it encounters an error on the
! command-line -- e.g. \programopt{-n4x} where \programopt{-n} is an
integer-valued option. \module{optparse} prints your usage message to
stderr, followed by a useful and human-readable error message. Then
--- 579,583 ----
The one thing you need to know for basic usage is how
\module{optparse} behaves when it encounters an error on the
! command-line --- e.g. \programopt{-n4x} where \programopt{-n} is an
integer-valued option. \module{optparse} prints your usage message to
stderr, followed by a useful and human-readable error message. Then
***************
*** 550,555 ****
If you don't like this, subclass \class{OptionParser} and override the
! \method{error()} method. See section \ref{optparse-extending}:
! Extending \module{optparse}.
\subsubsection{Putting it all together\label{optparse-basic-summary}}
--- 586,591 ----
If you don't like this, subclass \class{OptionParser} and override the
! \method{error()} method. See section~\ref{optparse-extending},
! ``Extending \module{optparse}.''
\subsubsection{Putting it all together\label{optparse-basic-summary}}
***************
*** 560,564 ****
from optparse import OptionParser
! [...]
def main ():
--- 596,600 ----
from optparse import OptionParser
! ...
def main ():
***************
*** 571,575 ****
parser.add_option("-q", "--quiet",
action="store_false", dest="verbose")
! [... more options ...]
(options, args) = parser.parse_args()
--- 607,611 ----
parser.add_option("-q", "--quiet",
action="store_false", dest="verbose")
! # more options ...
(options, args) = parser.parse_args()
***************
*** 580,584 ****
print "reading %s..." % options.filename
! [... go to work ...]
if __name__ == "__main__":
--- 616,620 ----
print "reading %s..." % options.filename
! # go to work ...
if __name__ == "__main__":
***************
*** 589,595 ****
This is reference documentation. If you haven't read the basic
! documentation in section \ref{optparse-basic-usage}, do so now.
! \subsubsection{Creating and populating the parser\label{optparse-creating-the-parser}}
There are several ways to populate the parser with options. One way
--- 625,632 ----
This is reference documentation. If you haven't read the basic
! documentation in section~\ref{optparse-basic-usage}, do so now.
! \subsubsection{Creating and populating the
! parser\label{optparse-creating-the-parser}}
There are several ways to populate the parser with options. One way
***************
*** 605,609 ****
\end{verbatim}
! (As of \module{optparse} 1.3, \function{make_option()} is an alias for
the \class{Option} class, ie. this just calls the \class{Option}
constructor. A future version of \module{optparse} will probably
--- 642,646 ----
\end{verbatim}
! (\function{make_option()} is an alias for
the \class{Option} class, ie. this just calls the \class{Option}
constructor. A future version of \module{optparse} will probably
***************
*** 618,622 ****
option_list = [make_option("-f", "--filename",
action="store", type="string", dest="filename"),
! # ... 17 other options ...
make_option("-q", "--quiet",
action="store_false", dest="verbose")]
--- 655,659 ----
option_list = [make_option("-f", "--filename",
action="store", type="string", dest="filename"),
! # 17 other options ...
make_option("-q", "--quiet",
action="store_false", dest="verbose")]
***************
*** 637,641 ****
This method makes it easier to track down exceptions raised by the
\class{Option} constructor, which are common because of the complicated
! interdependencies among the various keyword arguments -- if you get it
wrong, \module{optparse} raises \exception{OptionError}.
--- 674,678 ----
This method makes it easier to track down exceptions raised by the
\class{Option} constructor, which are common because of the complicated
! interdependencies among the various keyword arguments --- if you get it
wrong, \module{optparse} raises \exception{OptionError}.
***************
*** 766,771 ****
\var{nargs} > 1, multiple arguments will be consumed from the command
line; all will be converted according to \var{type} and stored to
! \var{dest} as a tuple. See section \ref{optparse-option-types}:
! Option types below.
If \var{choices} is supplied (a list or tuple of strings), the type
--- 803,808 ----
\var{nargs} > 1, multiple arguments will be consumed from the command
line; all will be converted according to \var{type} and stored to
! \var{dest} as a tuple. See section~\ref{optparse-option-types},
! ``Option types'' below.
If \var{choices} is supplied (a list or tuple of strings), the type
***************
*** 872,876 ****
\end{verbatim}
! See Error handling (section \ref{optparse-error-handling}) for
information on how \module{optparse} deals with something like
\samp{--tracks=x}.
--- 909,913 ----
\end{verbatim}
! See ``Error handling'' (section~\ref{optparse-error-handling}) for
information on how \module{optparse} deals with something like
\samp{--tracks=x}.
***************
*** 917,922 ****
\end{verbatim}
! Callback options are covered in detail in section
! \ref{optparse-callback-options}: Callback Options.
\term{help} [required: none]
--- 954,959 ----
\end{verbatim}
! Callback options are covered in detail in
! section~\ref{optparse-callback-options} ``Callback Options.''
\term{help} [required: none]
***************
*** 978,982 ****
-- long and complex are there mainly for completeness.) It's easy to
add new option types by subclassing the \class{Option} class; see
! section \ref{optparse-extending}: Extending \module{optparse}.
Arguments to string options are not checked or converted in any way:
--- 1015,1019 ----
-- long and complex are there mainly for completeness.) It's easy to
add new option types by subclassing the \class{Option} class; see
! section~\ref{optparse-extending}, ``Extending \module{optparse}.''
Arguments to string options are not checked or converted in any way:
***************
*** 1037,1041 ****
\begin{verbatim}
parser.add_option("-n", "--dry-run", ...)
! [...]
parser.add_option("-n", "--noisy", ...)
\end{verbatim}
--- 1074,1078 ----
\begin{verbatim}
parser.add_option("-n", "--dry-run", ...)
! ...
parser.add_option("-n", "--noisy", ...)
\end{verbatim}
***************
*** 1045,1052 ****
On the assumption that this is usually a mistake, \module{optparse}
! 1.2 and later raise an exception (\exception{OptionConflictError}) by
! default when this happens. Since this is an easily-fixed programming
! error, you shouldn't try to catch this exception -- fix your mistake
! and get on with life.
Sometimes, you want newer options to deliberately replace the option
--- 1082,1089 ----
On the assumption that this is usually a mistake, \module{optparse}
! raises an exception (\exception{OptionConflictError}) by default when
! this happens. Since this is an easily-fixed programming error, you
! shouldn't try to catch this exception --- fix your mistake and get on
! with life.
Sometimes, you want newer options to deliberately replace the option
***************
*** 1086,1090 ****
\begin{verbatim}
parser.add_option("-n", "--dry-run", ..., help="original dry-run option")
! [...]
parser.add_option("-n", "--noisy", ..., help="be noisy")
\end{verbatim}
--- 1123,1127 ----
\begin{verbatim}
parser.add_option("-n", "--dry-run", ..., help="original dry-run option")
! ...
parser.add_option("-n", "--noisy", ..., help="be noisy")
\end{verbatim}
***************
*** 1101,1105 ****
options:
--dry-run original dry-run option
! [...]
-n, --noisy be noisy
\end{verbatim}
--- 1138,1142 ----
options:
--dry-run original dry-run option
! ...
-n, --noisy be noisy
\end{verbatim}
***************
*** 1122,1126 ****
\begin{verbatim}
options:
! [...]
-n, --noisy be noisy
--dry-run new dry-run option
--- 1159,1163 ----
\begin{verbatim}
options:
! ...
-n, --noisy be noisy
--dry-run new dry-run option
***************
*** 1148,1152 ****
\end{verbatim}
! Note that you supply a function object here -- so you must have
already defined a function \function{my_callback()} when you define
the callback option. In this simple case, \module{optparse} knows
--- 1185,1189 ----
\end{verbatim}
! Note that you supply a function object here --- so you must have
already defined a function \function{my_callback()} when you define
the callback option. In this simple case, \module{optparse} knows
***************
*** 1200,1204 ****
is the option string seen on the command-line that's triggering the
callback. (If an abbreviated long option was used, \var{opt} will be
! the full, canonical option string -- e.g. if the user puts
\longprogramopt{foo} on the command-line as an abbreviation for
\longprogramopt{foobar}, then \var{opt} will be
--- 1237,1241 ----
is the option string seen on the command-line that's triggering the
callback. (If an abbreviated long option was used, \var{opt} will be
! the full, canonical option string --- e.g. if the user puts
\longprogramopt{foo} on the command-line as an abbreviation for
\longprogramopt{foobar}, then \var{opt} will be
***************
*** 1209,1213 ****
\module{optparse} will only expect an argument if \var{type} is
set; the type of \var{value} will be the type implied by the
! option's type (see \ref{optparse-option-types}: Option types). If
\var{type} for this option is None (no argument expected), then
\var{value} will be None. If \samp{nargs > 1}, \var{value} will
--- 1246,1250 ----
\module{optparse} will only expect an argument if \var{type} is
set; the type of \var{value} will be the type implied by the
! option's type (see~\ref{optparse-option-types}, ``Option types''). If
\var{type} for this option is None (no argument expected), then
\var{value} will be None. If \samp{nargs > 1}, \var{value} will
***************
*** 1290,1294 ****
raise OptionValueError("can't use -a after -b")
parser.values.a = 1
! [...]
parser.add_option("-a", action="callback", callback=check_order)
parser.add_option("-b", action="store_true", dest="b")
--- 1327,1331 ----
raise OptionValueError("can't use -a after -b")
parser.values.a = 1
! ...
parser.add_option("-a", action="callback", callback=check_order)
parser.add_option("-b", action="store_true", dest="b")
***************
*** 1305,1309 ****
raise OptionValueError("can't use %s after -b" % opt)
setattr(parser.values, option.dest, 1)
! [...]
parser.add_option("-a", action="callback", callback=check_order, dest='a')
parser.add_option("-b", action="store_true", dest="b")
--- 1342,1346 ----
raise OptionValueError("can't use %s after -b" % opt)
setattr(parser.values, option.dest, 1)
! ...
parser.add_option("-a", action="callback", callback=check_order, dest='a')
parser.add_option("-b", action="store_true", dest="b")
***************
*** 1311,1315 ****
\end{verbatim}
! Of course, you could put any condition in there -- you're not limited
to checking the values of already-defined options. For example, if
you have options that should not be called when the moon is full, all
--- 1348,1352 ----
\end{verbatim}
! Of course, you could put any condition in there --- you're not limited
to checking the values of already-defined options. For example, if
you have options that should not be called when the moon is full, all
***************
*** 1321,1325 ****
raise OptionValueError("%s option invalid when moon full" % opt)
setattr(parser.values, option.dest, 1)
! [...]
parser.add_option("--foo",
action="callback", callback=check_moon, dest="foo")
--- 1358,1362 ----
raise OptionValueError("%s option invalid when moon full" % opt)
setattr(parser.values, option.dest, 1)
! ...
parser.add_option("--foo",
action="callback", callback=check_moon, dest="foo")
***************
*** 1343,1347 ****
def store_value (option, opt, value, parser):
setattr(parser.values, option.dest, value)
! [...]
parser.add_option("--foo",
action="callback", callback=store_value,
--- 1380,1384 ----
def store_value (option, opt, value, parser):
setattr(parser.values, option.dest, value)
! ...
parser.add_option("--foo",
action="callback", callback=store_value,
***************
*** 1359,1363 ****
arguments. For this case, you have to write a callback;
\module{optparse} doesn't provide any built-in capabilities for it.
! You have to deal with the full-blown syntax for conventional Unix
command-line parsing. (Previously, \module{optparse} took care of
this for you, but I got it wrong. It was fixed at the cost of making
--- 1396,1400 ----
arguments. For this case, you have to write a callback;
\module{optparse} doesn't provide any built-in capabilities for it.
! You have to deal with the full-blown syntax for conventional \UNIX{}
command-line parsing. (Previously, \module{optparse} took care of
this for you, but I got it wrong. It was fixed at the cost of making
***************
*** 1409,1413 ****
setattr(parser.values, option.dest, value)
! [...]
parser.add_option("-c", "--callback",
action="callback", callback=varargs)
--- 1446,1450 ----
setattr(parser.values, option.dest, value)
! ...
parser.add_option("-c", "--callback",
action="callback", callback=varargs)
***************
*** 1651,1655 ****
\begin{enumerate}
\item subclass OptionParser and override the error() method
! \item subclass Option and override the take_action() method -- you'll
need to provide your own handling of the "help" action that
doesn't call sys.exit()
--- 1688,1692 ----
\begin{enumerate}
\item subclass OptionParser and override the error() method
! \item subclass Option and override the take_action() method --- you'll
need to provide your own handling of the "help" action that
doesn't call sys.exit()
***************
*** 1691,1693 ****
are present after parsing:
! \verbatiminput{required_2.py}
\ No newline at end of file
--- 1728,1730 ----
are present after parsing:
! \verbatiminput{required_2.py}