classification
Title: argparse optional arguments should follow getopt_long(3)
Type: behavior Stage:
Components: Library (Lib) Versions: Python 3.1, Python 3.2, Python 3.3, Python 2.7
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: Nosy List: bethard, mamikonyan, r.david.murray
Priority: normal Keywords:

Created on 2012-03-30 01:16 by mamikonyan, last changed 2012-07-21 20:28 by bethard. This issue is now closed.

Messages (4)
msg157115 - (view) Author: Ernest N. Mamikonyan (mamikonyan) Date: 2012-03-30 01:20
The nargs='?' option should probably follow the getopt_long(1) convention and only consume an (optional) argument if it's in the same argv element, i.e., without a space. Otherwise, it can only be given as the last option on the command-line. For example, in

./prog -a ARG1 ARG2

ARG1 should not be considered an optional argument to -a, but here, it should:

./prog -aARG1 ARG2
msg157118 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2012-03-30 01:31
If I understand correctly, this would be a backward incompatible change, so I doubt it will be accepted.  Maybe there's some other way to achieve the same end?
msg157284 - (view) Author: Ernest N. Mamikonyan (mamikonyan) Date: 2012-04-01 13:18
Yes, it is incompatible. But that's because the current behavior is 
incompatible with standard (getopt_long(3)) practice. Or perhaps, you 
can add another option that implements the optional argument semantics 
of GNU's getopt_long(3).

In any case, I understand. If you figure out some other way, please let 
me know (or document it).

Thanks much,
Ernest Mamikonyan
msg166063 - (view) Author: Steven Bethard (bethard) * (Python committer) Date: 2012-07-21 20:28
I don't think this is going to change.

It's basically a consequence of having a unified handling of nargs='?', nargs='*', nargs='+', etc. These will all consume as many arguments as they can, and argparse doesn't distinguish between arguments that are concatenated to options and arguments that aren't. (And you couldn't concatenate a whole '+' style argument to the option anyway.)

If you really want getopt-style parsing instead, the getopt module is still available. ;-)
History
Date User Action Args
2012-07-21 20:28:19bethardsetstatus: open -> closed
resolution: wont fix
messages: + msg166063
2012-04-01 13:18:22mamikonyansetmessages: + msg157284
2012-03-30 01:31:47r.david.murraysetnosy: + r.david.murray, bethard
messages: + msg157118
2012-03-30 01:21:59mamikonyansettitle: argparse optional arguments sh -> argparse optional arguments should follow getopt_long(3)
2012-03-30 01:20:49mamikonyansetmessages: + msg157115
2012-03-30 01:16:14mamikonyancreate