Steven Bethard steven.beth...@gmail.com added the comment:
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
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:
--
title: argparse optional arguments sh - argparse optional arguments should
follow getopt_long(3)
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14449
R. David Murray rdmur...@bitdance.com added the comment:
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?
--
nosy: +bethard, r.david.murray
