New submission from Aaron Sherman <a...@ajs.com>: 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. ---------- assignee: georg.brandl components: Documentation messages: 84103 nosy: ajs, georg.brandl severity: normal status: open title: optparse type: behavior versions: Python 2.6, Python 3.0 _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue5555> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
