Message84103
First off, I want to be clear that this isn't a request for changes to
functionality, nor for debate over decisions which have already been
made. This is purely a request for correction to mis-statements about
the nature and origins of optparse's handling in its documentation.
This is an edited-down excerpt form the optparse documentation from:
http://docs.python.org/library/optparse.html
"... the traditional Unix syntax is a hyphen (“-“) followed by a single
letter [...] Some other option syntaxes that the world has seen include:
* a hyphen followed by a few letters, e.g. "-pf" [...]
[...] These option syntaxes are not supported by optparse, and they
never will be. This is deliberate: the first three are non-standard on
any environment[...]"
While, obviously, optparse is free to choose whatever model of option
parsing the developers like, the above text should be removed or
corrected. Traditional Unix command-line usage is detailed in the POSIX
specification's definition of various utilities and the optparse C
function as documented here:
http://www.opengroup.org/onlinepubs/009695399/functions/getopt.html
which lays out this example:
"This code accepts any of the following as equivalent:
cmd -ao arg path path
cmd -a -o arg path path"
Note that the concatenation of single-character arguments is, in fact,
in conformance to the POSIX standard, GNU coding conventions, and Unix
best-practices since at least the mid-1980s. This clearly contradicts
the statement from Python's documentation. For further reference, see:
any Unix or Unix-like system's "man 3 getopt"
http://www.faqs.org/docs/artu/ch10s05.html
http://www.gnu.org/prep/standards/standards.html#Command_002dLine-Interfaces
(which refers back to the "POSIX guidelines for the command-line options
of a program")
any Unix or Unix-like system's man pages for a plethora of core
utilities such as rm(1), ls(1), sh(1), cp(1), etc.
A more accurate statement would be:
"optparse has chosen to implement a subset of the GNU coding standard's
command line interface guidelines, allowing for both long and short
options, but not the POSIX-style concatenation of short options."
A rationale for that decision may or may not be included, but I won't
presume to write it since I'm not actually privy to that decision-making
process. |
|
Date |
User |
Action |
Args |
2009-03-24 18:01:15 | ajs | set | recipients:
+ ajs, georg.brandl |
2009-03-24 18:01:15 | ajs | set | messageid: <1237917675.54.0.817122476849.issue5555@psf.upfronthosting.co.za> |
2009-03-24 18:01:13 | ajs | link | issue5555 messages |
2009-03-24 18:01:11 | ajs | create | |
|