Ernest N. Mamikonyan ernest.mamikon...@gmail.com added the comment:
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
Changes by Ernest N. Mamikonyan ernest.mamikon...@gmail.com:
--
components: Library (Lib)
nosy: mamikonyan
priority: normal
severity: normal
status: open
title: argparse optional arguments sh
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3
New submission from Ernest N. Mamikonyan ernest.mamikon...@gmail.com:
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
Changes by Ernest N. Mamikonyan ernest.mamikon...@gmail.com:
--
title: argparse optional arguments sh - argparse optional arguments should
follow getopt_long(3)
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14449
