argparse already seems to support -- to indicate that what follows are positional arguments. However, I would like to parse something like:

./script.py --ignore one two -- COMMAND

I.e., --ignore is an nargs='+' argument, and I need a way to break out of --ignore and have argparse consider what follows on it's own merits. If COMMAND in the above example refers to a subparser, this won't work:

error: invalid choice: '--' (choose from 'command1', 'command2', 'command3')

I'm not sure what's the best solution here. Allowing -- here would change the semantics of forcing everything that follows to be positional arguments, since the subparser might have flags. I'm not sure if that is what is required by Unix conventions, but if not, then I think it makes sense to allow -- to be followed by a subparser.

It looks like, if accepted, this would be a feature request,so I'm marking it as such and setting versions to 3.2.  You'd have to provide a patch pretty soon to get it in to 3.2, though.

However, I'm guessing that this is something better off implemented via subclassing in your code, since it sounds like a fairly unusual command pattern.  (I've only ever seen options after a -- in a unix comand when those options were being passed unparsed to some *other* command that the first command was a wrapper for.)

I've added Steven as nosy, we'll see what he thinks.

This is closely related to issue 9338. The parser should know that your command line requires at least the COMMAND argument, so it should stop parsing in time for that. However, in the case of subcommands, even if we solved issue 9338, you would still get the behavior that

./script.py --ignore one two COMMAND arg1 arg2

would get parsed as "arg2" being the command. So I guess there still ought to be a way to tell argparse to stop parsing nargs='+' optionals.

Seems like there's also a bug in the current behavior - you should get an error saying that no command was given, not an error saying you issued the command "--".