traverseda
/
cpython
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Use TeX quotes -- ``foo'' -- as appropriate. 

Remove whitespace around em-dashes.
This commit is contained in:
Greg Ward 2003-05-03 19:41:45 +00:00
parent b4e3319302
commit bf8f1b55a8
1 changed files with 39 additions and 39 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

78
Doc/lib/liboptparse.tex
View File

@ -33,7 +33,7 @@ parser.add_option("-q", "--quiet",
\end{verbatim}
With these few lines of code, users of your script can now do the
"usual thing" on the command-line:
``usual thing'' on the command-line:
\begin{verbatim}
$ <yourscript> -f outfile --quiet
@ -188,7 +188,7 @@ execution of a program. In case it wasn't clear, options are usually
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
and \program{dd}---all of which are mutant oddballs that have been
rightly criticized for their non-standard syntax and confusing
interfaces.)
@ -228,18 +228,18 @@ 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 \emph{how} you get that
information from the user --- most people will give up and walk away
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:
if you make that many demands on your users, most of them will just give
up.
In short, try to minimize the amount of information that users are
absolutely required to supply --- use sensible defaults whenever
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
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
yourself!) with too much flexibility, so be careful there.
@ -281,7 +281,7 @@ strings. In this document, we'll only cover four of the things you
can put there: \var{action}, \var{type}, \var{dest} (destination), and
\var{help}.
\subsubsection{The "store" action\label{optparse-store-action}}
\subsubsection{The \var{store} action\label{optparse-store-action}}
The action tells \module{optparse} what to do when it sees one of the
option strings for this option on the command-line. For example, the
@ -289,7 +289,7 @@ action \var{store} means: 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, let's fill in the "..." of that last option:
For example, let's fill in the ``...'' of that last option:
\begin{verbatim}
parser.add_option("-f", "--file",
@ -308,7 +308,7 @@ args = ["-f", "foo.txt"]
\function{parse_args()}, it automatically uses \var{sys.argv[1:]}.)
When \module{optparse} sees the \programopt{-f}, it sucks in the next
argument --- ``foo.txt'' --- and stores it in the \var{filename}
argument---\code{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:
@ -316,20 +316,20 @@ from \function{parse_args()}, so:
print options.filename
\end{verbatim}
will print ``foo.txt''.
will print \code{foo.txt}.
Other option types supported by \module{optparse} are ``int'' and
``float''. Here's an option that expects an integer argument:
Other option types supported by \module{optparse} are \code{int} and
\code{float}. Here's an option that expects an integer argument:
\begin{verbatim}
parser.add_option("-n", type="int", dest="num")
\end{verbatim}
Note that I didn't supply a long option, which is perfectly acceptable.
I also didn't specify the action --- it defaults to ``store''.
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
option argument right up against the option---\programopt{-n42} (one
argument) is equivalent to \programopt{-n 42} (two arguments). :
\begin{verbatim}
@ -359,10 +359,10 @@ 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}}
\subsubsection{Other \var{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
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
\programopt{-v} and off with \programopt{-q}:
@ -374,7 +374,7 @@ 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.)
default values---see below.)
When \module{optparse} sees \programopt{-v} on the command line, it
sets the \var{verbose} attribute of the special {option values}
@ -474,16 +474,16 @@ best possible help message:
usage = "usage: %prog [options] arg1 arg2"
\end{verbatim}
\module{optparse} expands "\%prog" in the usage string to the name of the
\module{optparse} expands \samp{\%prog} in the usage string to the name of the
current script, ie. \code{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, \module{optparse} uses a bland but
sensible default: ``usage: \%prog [options]'', which is fine if your
sensible default: \code{"usage: \%prog [options]"}, which is fine if your
script doesn't take any positional arguments.
\item every option defines a help string, and doesn't worry about
line-wrapping --- \module{optparse} takes care of wrapping lines and
line-wrapping---\module{optparse} takes care of wrapping lines and
making the help output look good.
\item options that take a value indicate this fact in their
@ -497,7 +497,7 @@ Here, ``MODE'' is called the meta-variable: it stands for the argument
that the user is expected to supply to
\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
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
option description:
@ -578,7 +578,7 @@ $
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
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
it terminates (calls \function{sys.exit()}) with a non-zero exit
@ -673,7 +673,7 @@ parser.add_option("-q", "--quiet",
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
interdependencies among the various keyword arguments---if you get it
wrong, \module{optparse} raises \exception{OptionError}.
\method{add_option()} can be called in one of two ways:
@ -1084,7 +1084,7 @@ parser.add_option("-n", "--noisy", ...)
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
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
@ -1185,7 +1185,7 @@ to call:
parser.add_option("-c", callback=my_callback)
\end{verbatim}
Note that you supply a function object here --- so you must have
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
nothing about the arguments the \programopt{-c} option expects to
@ -1237,7 +1237,7 @@ is the \class{Option} instance that's calling the callback.
\term{opt}
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
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
\longprogramopt{foobar}.)
@ -1348,7 +1348,7 @@ parser.add_option("-b", action="store_true", dest="b")
parser.add_option("-c", action="callback", callback=check_order, dest='c')
\end{verbatim}
Of course, you could put any condition in there --- you're not limited
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
you have to do is this:
@ -1363,7 +1363,7 @@ parser.add_option("--foo",
action="callback", callback=check_moon, dest="foo")
\end{verbatim}
(The definition of is_full_moon() is left as an exercise for the
(The definition of \code{is_full_moon()} is left as an exercise for the
reader.)
\strong{Fixed arguments}
@ -1567,20 +1567,20 @@ Adding new actions is a bit trickier, because you have to understand
that \module{optparse} has a couple of classifications for actions:
\begin{definitions}
\term{"store" actions}
\term{``store'' actions}
actions that result in \module{optparse} storing a value to an attribute
of the OptionValues instance; these options require a 'dest'
of the OptionValues instance; these options require a \var{dest}
attribute to be supplied to the Option constructor
\term{"typed" actions}
\term{``typed'' actions}
actions that take a value from the command line and expect it to be
of a certain type; or rather, a string that can be converted to a
certain type. These options require a 'type' attribute to the
certain type. These options require a \var{type} attribute to the
Option constructor.
\end{definitions}
Some default ``store'' actions are ``store'', ``store_const'',
``append'', and ``count''. The default ``typed'' actions are
``store'', ``append'', and ``callback''.
Some default ``store'' actions are \var{store}, \var{store_const},
\var{append}, and \var{count}. The default ``typed'' actions are
\var{store}, \var{append}, and \var{callback}.
When you add an action, you need to decide if it's a ``store'' action,
a ``typed'', neither, or both. Three class attributes of
@ -1590,10 +1590,10 @@ a ``typed'', neither, or both. Three class attributes of
All actions must be listed as strings in ACTIONS.
\end{memberdesc}
\begin{memberdesc}{STORE_ACTIONS}
"store" actions are additionally listed here.
``store'' actions are additionally listed here.
\end{memberdesc}
\begin{memberdesc}{TYPED_ACTIONS}
"typed" actions are additionally listed here.
``typed'' actions are additionally listed here.
\end{memberdesc}
In order to actually implement your new action, you must override
@ -1688,8 +1688,8 @@ You'll have to
\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
\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()
\end{enumerate}