This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author cben
Recipients Christophe.Guillon, abacabadabacaba, amcnabb, andersk, bethard, cben, danielsh, davidben, drm, eric.araujo, eric.smith, gdb, gfxmonk, memeplex, nelhage, paul.j3, r.david.murray, skilletaudio
Date 2016-04-11.22:03:47
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
+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.


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.
Date User Action Args
2016-04-11 22:03:48cbensetrecipients: + cben, amcnabb, bethard, eric.smith, eric.araujo, r.david.murray, memeplex, gfxmonk, andersk, abacabadabacaba, gdb, nelhage, drm, davidben, paul.j3, skilletaudio, Christophe.Guillon, danielsh
2016-04-11 22:03:47cbensetmessageid: <>
2016-04-11 22:03:47cbenlinkissue9334 messages
2016-04-11 22:03:47cbencreate