Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
C
cpython
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
0
Issues
0
List
Boards
Labels
Milestones
Merge Requests
0
Merge Requests
0
Analytics
Analytics
Repository
Value Stream
Wiki
Wiki
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Commits
Issue Boards
Open sidebar
Kirill Smelkov
cpython
Commits
368a0276
Commit
368a0276
authored
Jul 16, 2003
by
Fred Drake
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Lots of markup cleanups to avoid warnings from the GNU info generation;
these make sense even without that processing chain.
parent
3e1fa4fc
Changes
3
Hide whitespace changes
Inline
Side-by-side
Showing
3 changed files
with
23 additions
and
23 deletions
+23
-23
Doc/lib/liboptparse.tex
Doc/lib/liboptparse.tex
+20
-20
Doc/lib/libpdb.tex
Doc/lib/libpdb.tex
+1
-1
Doc/lib/librfc822.tex
Doc/lib/librfc822.tex
+2
-2
No files found.
Doc/lib/liboptparse.tex
View file @
368a0276
...
...
@@ -82,14 +82,14 @@ First, we need to establish some terminology.
a chunk of text that a user enters on the command-line, and that the
shell passes to
\cfunction
{
execl()
}
or
\cfunction
{
execv()
}
. In
Python, arguments are elements of
\
var
{
sys.argv[1:]
}
. (
\var
{
sys.argv[0]
}
is the name of the program
\
code
{
sys.argv[1:]
}
. (
\code
{
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 is occasionally desirable to use an argument list other than
\
var
{
sys.argv[1:]
}
, so you should read ``argument'' as ``an element of
\
var
{
sys.argv[1:]
}
, or of some other list provided as a substitute for
\
var
{
sys.argv[1:]
}
''.
\
code
{
sys.argv[1:]
}
, so you should read ``argument'' as ``an element of
\
code
{
sys.argv[1:]
}
, or of some other list provided as a substitute for
\
code
{
sys.argv[1:]
}
''.
\term
{
option
}
an argument used to supply extra information to guide or customize
...
...
@@ -306,10 +306,10 @@ args = ["-f", "foo.txt"]
\end{verbatim}
(Note that if you don't pass an argument list to
\function
{
parse
_
args()
}
, it automatically uses
\
var
{
sys.argv[1:]
}
.)
\function
{
parse
_
args()
}
, it automatically uses
\
code
{
sys.argv[1:]
}
.)
When
\module
{
optparse
}
sees the
\programopt
{
-f
}
, it consumes the next
argument---
\code
{
foo.txt
}
---and stores it in the
\
va
r
{
filename
}
argument---
\code
{
foo.txt
}
---and stores it in the
\
membe
r
{
filename
}
attribute of a special object. That object is the first return value
from
\function
{
parse
_
args()
}
, so:
...
...
@@ -354,9 +354,9 @@ parser.add_option("-f", "--file", dest="filename")
If you don't supply a destination,
\module
{
optparse
}
figures out a
sensible default from the option strings: if the first long option
string is
\longprogramopt
{
foo-bar
}
, then the default destination is
\
va
r
{
foo
_
bar
}
. If there are no long option strings,
\
membe
r
{
foo
_
bar
}
. If there are no long option strings,
\module
{
optparse
}
looks at the first short option: the default
destination for
\programopt
{
-f
}
is
\
va
r
{
f
}
.
destination for
\programopt
{
-f
}
is
\
membe
r
{
f
}
.
Adding types is fairly easy; please refer to
section~
\ref
{
optparse-adding-types
}
, ``Adding new types.''
...
...
@@ -380,8 +380,8 @@ 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 sets
\
var
{
options.verbose
}
to
\code
{
True
}
; when it sees
\programopt
{
-q
}
, it
sets
\
var
{
options.verbose
}
to
\code
{
False
}
.
\
code
{
options.verbose
}
to
\code
{
True
}
; when it sees
\programopt
{
-q
}
, it
sets
\
code
{
options.verbose
}
to
\code
{
False
}
.
\subsubsection
{
Setting default values
\label
{
optparse-setting-default-values
}}
...
...
@@ -394,7 +394,7 @@ address that need, \module{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
\module
{
optparse
}
to set
\
va
r
{
verbose
}
to
\code
{
True
}
unless
\module
{
optparse
}
to set
\
membe
r
{
verbose
}
to
\code
{
True
}
unless
\programopt
{
-q
}
is seen, then we can do this:
\begin{verbatim}
...
...
@@ -411,7 +411,7 @@ parser.add_option("-q", action="store_false", dest="verbose", default=True)
Those are equivalent because you're supplying a default value for the
option's
\emph
{
destination
}
, and these two options happen to have the same
destination (the
\
va
r
{
verbose
}
variable).
destination (the
\
membe
r
{
verbose
}
variable).
Consider this:
...
...
@@ -420,7 +420,7 @@ parser.add_option("-v", action="store_true", dest="verbose", default=False)
parser.add
_
option("-q", action="store
_
false", dest="verbose", default=True)
\end{verbatim}
Again, the default value for
\
va
r
{
verbose
}
will be
\code
{
True
}
: the last
Again, the default value for
\
membe
r
{
verbose
}
will be
\code
{
True
}
: the last
default value supplied for any particular destination is the one that
counts.
...
...
@@ -428,7 +428,7 @@ counts.
The last feature that you will use in every script is
\module
{
optparse
}
's ability to generate help messages. All you have
to do is supply a
\var
{
help
}
value
when you add an option. Let's
to do is supply a
\var
{
help
}
argument
when you add an option. Let's
create a new parser and populate it with user-friendly (documented)
options:
...
...
@@ -738,7 +738,7 @@ parser.parse_args()
\end
{
verbatim
}
one of the first things
\module
{
optparse
}
does is create a
\
var
{
values
}
object:
\
code
{
values
}
object:
\begin
{
verbatim
}
values
=
Values
()
...
...
@@ -786,7 +786,7 @@ value according to \var{type} and stored in \var{dest}. If
\code
{
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.
``Option types
,
'' below.
If
\var
{
choices
}
(
a sequence of strings
)
is supplied, the type
defaults to ``choice''.
...
...
@@ -795,9 +795,9 @@ If \var{type} is not supplied, it defaults to ``string''.
If
\var
{
dest
}
is not supplied,
\module
{
optparse
}
derives a
destination from the first long option strings
(
e.g.,
\longprogramopt
{
foo
-
bar
}
becomes
\
va
r
{
foo
_
bar
}
)
. If there are no long
\longprogramopt
{
foo
-
bar
}
becomes
\
membe
r
{
foo
_
bar
}
)
. If there are no long
option strings,
\module
{
optparse
}
derives a destination from the first
short option string
(
e.g.,
\programopt
{
-
f
}
becomes
\
va
r
{
f
}
)
.
short option string
(
e.g.,
\programopt
{
-
f
}
becomes
\
membe
r
{
f
}
)
.
Example:
...
...
@@ -1217,7 +1217,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
---
for example,
if the user puts
\longprogramopt
{
foo
}
on the command
-
line as an abbreviation for
\longprogramopt
{
foobar
}
, then
\var
{
opt
}
will be
\longprogramopt
{
foobar
}
.
)
...
...
@@ -1676,7 +1676,7 @@ You'll have to
The second, much more complex, possibility is to override the
command
-
line syntax implemented by
\module
{
optparse
}
. In this case,
you'd leave the whole machinery of option actions and types alone, but
rewrite the code that processes
\
var
{
sys.argv
}
. You'll need to
rewrite the code that processes
\
code
{
sys.argv
}
. You'll need to
subclass
\class
{
OptionParser
}
in any case; depending on how radical a
rewrite you want, you'll probably need to override one or all of
\method
{
parse
_
args
()
}
,
\method
{_
process
_
long
_
opt
()
}
, and
...
...
Doc/lib/libpdb.tex
View file @
368a0276
...
...
@@ -265,7 +265,7 @@ It should be noted that not all jumps are allowed --- for instance it
is not possible to jump into the middle of a
\keyword
{
for
}
loop or out
of a
\keyword
{
finally
}
clause.
\item
[l(ist) \optional{\var{first
\optional{,
last}}}]
\item
[l(ist) \optional{\var{first
}\optional{, \var{
last}}}]
List source code for the current file. Without arguments, list 11
lines around the current line or continue the previous listing. With
...
...
Doc/lib/librfc822.tex
View file @
368a0276
...
...
@@ -255,10 +255,10 @@ there is no header matching \var{name}, or it is unparsable, return
In particular:
\code
{
\var
{
m
}
[name]
}
is like
\code
{
\var
{
m
}
.getheader(name)
}
but raises
\exception
{
KeyError
}
if
there is no matching header; and
\code
{
len(
\var
{
m
}
)
}
,
\code
{
\var
{
m
}
.get(
\var
{
name
}
\optional
{
\var
{
,
default
}}
)
}
,
\code
{
\var
{
m
}
.get(
\var
{
name
}
\optional
{
,
\var
{
default
}}
)
}
,
\code
{
\var
{
m
}
.has
_
key(
\var
{
name
}
)
}
,
\code
{
\var
{
m
}
.keys()
}
,
\code
{
\var
{
m
}
.values()
}
\code
{
\var
{
m
}
.items()
}
, and
\code
{
\var
{
m
}
.setdefault(
\var
{
name
}
\optional
{
\var
{
,
default
}}
)
}
act as
\code
{
\var
{
m
}
.setdefault(
\var
{
name
}
\optional
{
,
\var
{
default
}}
)
}
act as
expected, with the one difference that
\method
{
setdefault()
}
uses
an empty string as the default value.
\class
{
Message
}
instances
also support the mapping writable interface
\code
{
\var
{
m
}
[name] =
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment