Cherniavsky Beni added the comment:
+1, is there anything missing to apply Paul's patch?
Can I additional suggest a change to the error message, e.g.:
$ prog --foo -bar
prog: error: argument --foo: expected one argument
(tip: use --foo=-bar to force interpretation as argument of --foo)
This can be safely added in the current mode with no opt-in required, and will
relieve the immediate "but what can I do?" confusions of users. The workaround
is hard to discover otherwise, as `--foo=x` is typically equivalent to `--foo
x`.
--- more discussion, though I suspect it's not productive ---
I've tried to find what the GNU Standards or POSIX say about this and was
surprised to see neither explains how exactly `--opt_with_mandatory_argument
-quux` behaves.
man getopt says:
If such a character is followed by a colon, the option requires an
argument, so getopt() places a pointer to the following text in the same
argv-element, or the text of the following argv-element, in optarg. Two colons
mean an option takes an optional arg; if there is text in the current
argv-element (i.e., in the same word as the option name itself, for example,
"-oarg"), then it is returned in optarg, otherwise optarg is set to zero. This
is a GNU extension.
POSIX similarly does explain that an optional arg after an option must follow
within the same argument:
(2)(b) If the SYNOPSIS shows an optional option-argument (as with [ -f[
option_argument]] in the example), a conforming application shall place any
option-argument for that option directly adjacent to the option in the same
argument string, without intervening <blank> characters. If the utility
receives an argument containing only the option, it shall behave as specified
in its description for an omitted option-argument; it shall not treat the next
argument (if any) as the option-argument for that option.
-- http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html
Anyway, every argument parsing library I've ever seen parses options in a
left-to-right pass, consuming non-optional arguments after an option whatever
they look like. I've never seen a difference between `--foo bar` and
`--foo=bar` when bar is *non-optional*.
Both behaviors (--opt_with_mandatory_argument bar,
--opt_with_optional_argument[=bar]) were clearly designed to avoid ambiguity.
Whereas argparse innovated some constructs eg. '--opt', nargs='*' that are
inherently ambiguous. But for the simple constructs, most notably nargs=1,
there should be a way to get the traditional unix meaning.
----------
nosy: +cben
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue9334>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
