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 elsdoerfer
Recipients elsdoerfer
Date 2010-08-08.01:26:42
SpamBayes Score 1.9492049e-07
Marked as misclassified No
Message-id <1281230805.22.0.0952279078785.issue9540@psf.upfronthosting.co.za>
In-reply-to
Content
>>> parser = argparse.ArgumentParser()
>>> subparsers = parser.add_subparsers(title="commands")
>>> subparser = subparsers.add_parser('make')
>>> parser.add_argument('jobs', nargs='*')
>>> parser.print_help()
usage: [-h] {make} ... [jobs [jobs ...]]

While the printed usage looks innocuous enough, argparser isn't actually able to parse this the way I expect: The positional argument never get's to handle any jobs given, as apparently everything after the command is handled by the subparser:

>>> parser.parse_args(['make', 'something'])
usage:  make [-h]
 make: error: unrecognized arguments: something

It seems that argparse, upon determining that the subparser can't handle a positional argument, could break out of the subparser, and let the parent parser continue. If necessary, as further help for argparse on how to resolve such situations, a parameter could be added to add_subparsers() which would allow the user to indicate that this group of subparsers should not support positional arguments.

The usage string should then print as:

>>> parser.print_help()
usage: [-h] {make} [jobs [jobs ...]]

That is, without the "..." after the command.

Finally, if it is decided that the feature will not be added, argparse should not allow the user to add positional arguments after a subparser.
History
Date User Action Args
2010-08-08 01:26:45elsdoerfersetrecipients: + elsdoerfer
2010-08-08 01:26:45elsdoerfersetmessageid: <1281230805.22.0.0952279078785.issue9540@psf.upfronthosting.co.za>
2010-08-08 01:26:43elsdoerferlinkissue9540 messages
2010-08-08 01:26:42elsdoerfercreate