[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

[Cherniavsky Beni]

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 <report at bugs.python.org>
<http://bugs.python.org/issue9334>
_______________________________________