This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author nvie
Recipients nvie
Date 2010-07-13.21:29:46
SpamBayes Score 1.2974057e-05
Marked as misclassified No
Message-id <>
**NOTE**: This is a re-post of

What steps will reproduce the problem?
parser = argparse.ArgumentParser()
sub = parser.add_subparsers()
parser.add_argument("paths", "+")
parser.parse_args(["foo", "bar"])

What is the expected output? What do you see instead?
Expected behavior is that, failing to match one of the subparser inputs
("info"), the parser checks if the argument matches any of the top-level
arguments, in this case the 'paths' multi-arg. In other words, it should be
possible to make the subparser be optional, such that when the subparser
argument fails to retrieve any valid subparser, the remaining args are
parsed as if no subparser exists. At present, it does not seem possible to
make a subparser be optional at all.
Perhaps this could be exposed to the user as:
or something to that effect. Or, allow a default subparser to be specified.

sub = parser.add_subparsers()
info = sub.add_parser("info")
main = sub.add_parser("main")
sub.default = main

I'm sure the point will come up that the current behavior is correct,
because given a subparser like "info", a user could easily make a mistake
like "myapp ino foo bar" and rather than get a safe error be given
something unexpected. For this reason, I think the default behavior is
usually going to be correct. BUT, it would still be nice if it could be
optional, so that developers could be free to make that call. Sometimes the
potential user errors aren't really an issue, and having to explicitly set
a subparse arg every time can be a nuissance.
Date User Action Args
2010-07-13 21:29:49nviesetrecipients: + nvie
2010-07-13 21:29:49nviesetmessageid: <>
2010-07-13 21:29:47nvielinkissue9253 messages
2010-07-13 21:29:46nviecreate