From bf8f1b55a814e671cc595244c0dad3035c34cc47 Mon Sep 17 00:00:00 2001 From: Greg Ward Date: Sat, 3 May 2003 19:41:45 +0000 Subject: [PATCH] Use TeX quotes -- ``foo'' -- as appropriate. Remove whitespace around em-dashes. --- Doc/lib/liboptparse.tex | 78 ++++++++++++++++++++--------------------- 1 file changed, 39 insertions(+), 39 deletions(-) diff --git a/Doc/lib/liboptparse.tex b/Doc/lib/liboptparse.tex index 8b1b40483d2..0cfbb9cddfc 100644 --- a/Doc/lib/liboptparse.tex +++ b/Doc/lib/liboptparse.tex @@ -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} $ -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}