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 [-h] {ls,du} ... vm [vm ...]

but only accept one vm.

I would suspect a bug when parsing the arguments (as the help meets the desired behavior).

Attached is a little script to reproduce the error.

Thank you !

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 nargs for a subparser is 'A...' (argparse.PARSER), which is similar to '+' (it takes one or more strings)

    parser2=ArgumentParser()
    parser2.add_argument('arg1',nargs='A...')
    parser2.add_argument('arg2',nargs='+')
    parser2.parse_args(['create','test','test2'])

produces

    Namespace(arg1=['create', 'test'], arg2=['test2'])

Notice how 2 of the strings are allocated to arg1, and only 1 to arg2. arg2 is happy with just 1, so arg1 gets the rest.

In your example it's the subparser that is issuing the 'unrecognized arguments' message, because it doesn't have a positional argument that would take it.

Having more than one positional that takes are variable number of arguments is tricky.  I find it helpful to think in terms of how `re` would handle a pattern like `(A+)(A*)(A)`.

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.

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 not feasible, I would suggest modifying the documentation, or having a warning, or something to let people know. If this is possible.

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)

        if not argv:
            return args

        # save old actions, before rerunning the parser without the _SubParsersActions
        self._old_actions = self._actions.copy()
        self._actions = [action for action in self._old_actions if not isinstance(action, _SubParsersAction)]

        # parse the remaining command line
        args2, argv2 = self.parse_known_args(argv, None)

        self._actions = self._old_actions.copy()

        if argv2:
            msg = _('unrecognized arguments: %s')
            self.error(msg % ' '.join(argv2))

        for key, value in vars(args2).items():
            if isinstance(value, collections.Iterable):
                setattr(args, key, [value for value in itertools.chain(getattr(args, key), value)])

        return args


I know this is not generic enough and not cleanly done. However, would this be an interesting addition to the argumentparser ? If so, I can try to make a generic implementation, which would allow having multiple arguments after a subparser which did not match them

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 positionals until the argv list is done.  The `consume_loop` method in that patch tries various allocations of argv strings between optionals and positionals.  It performs 'dry' runs until it finds something that consumes most of the strings, and then does the actual parsing with changes to the namespace.

The idea might be adapted to work with subparsers, paying attention, as you do, to the 'extras' from parse_known_args.  But it might be hard to reliably perform a 'dry' run when subparsers are involved.

I suspect that any change along this line will be too complex to ever be the default behavior.  The chances of messing with backward compatibility are just too great.  It might pass as an alternative parsing call.

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