[issue14449] argparse optional arguments should follow getopt_long(3)

Steven Bethard 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 arguments that are concate

[issue14449] argparse optional arguments should follow getopt_long(3)

Ernest N. Mamikonyan 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 getopt_long(3). In any case, I und

[issue14449] argparse optional arguments should follow getopt_long(3)

R. David Murray 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 ___ Python tracker

[issue14449] argparse optional arguments should follow getopt_long(3)

Changes by Ernest N. Mamikonyan : -- title: argparse optional arguments sh -> argparse optional arguments should follow getopt_long(3) ___ Python tracker ___ ___