Benjamin Schubert added the comment:
Ok, sorry for the delay.
I see your point and understand the difficulty of having done right.
Should I close the issue, or propose something else ?
Thanks
--
___
Python tracker rep...@bugs.python.org
Benjamin Schubert added the comment:
Thanks a lot for this explanation ! It is more clear now for why it is not
working.
However, I would suggest that the ArgumentParser should still try to match
anything the subparser could not, or would this be too complicated ?
Moreover, if this scheme is
Benjamin Schubert added the comment:
I solved my problem by subclassing the ArgumentParser and redefining parse_args
as follow :
class MultipleArgumentParser(ArgumentParser):
def parse_args(self, args=None, namespace=None):
args, argv = self.parse_known_args(args, namespace)
paul j3 added the comment:
Look at http://bugs.python.org/issue9338
argparse optionals with nargs='?', '*' or '+' can't be followed by positionals
That has a proposed patch that wraps the main argument consumption loop in
another loop.
The current loop alternatively consumes optionals and
New submission from Benjamin Schubert:
When creating a ArgumentParser on which we attach a subparser with different
options and then add a nargs=+ argument to the initial parser, the command
format string generated does not match the behavior.
for example it would generate :
argparse_error.py
paul j3 added the comment:
I wouldn't describe this as bug, just a nuance on how parsers and subparsers
play together.
To the main parser, the subparser argument looks like another positional. It
allocates strings to it and any following positionals based on their respective
'nargs'.
The
paul j3 added the comment:
And the behavior does match the help
{ls,du} ... vm [vm ...]
It's just that one of the strings is allocated to the first `...`, whereas you
expected it to be put in the second.
--
___
Python tracker
