Author paul.j3
Recipients DasIch, G2P, Julian, bethard, bewest, bkabrda, chris.jerdonek, csernazs, dsully, elsdoerfer, eric.araujo, labrat, nvie, paul.j3, r.david.murray, seblu, zzzeek
Date 2013-07-30.21:36:27
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1375220187.96.0.244131784282.issue9253@psf.upfronthosting.co.za>
In-reply-to
Content
"msg113512 - (view)	Author: Steven Bethard (bethard) 
Seems like there's minimally the bug that argparse should currently throw an error if you add an argument after subparsers (since that argument will never be parsed under the current semantics)."

This isn't quite right.  If the main usage signature is:

usage: PROG [-h] foo {one,two} ... baz

the parser._match_arguments_partial() method will allocate the 1st string to 'foo', the last to 'baz', and pass the rest to the subparser(s).  It doesn't know how many the subparsers can use, but it knows that 'baz' requires one.  From the standpoint of matching argument strings and arguments, a subparser is essentially a '+' positional.

On the other hand if 'baz' (the positional after the subparser) was '*' or '?' it would not get any strings.

If it is possible that subparser(s) doesn't need all the strings passed to it, the user could use 'parse_known_args', and deal with the unparsed strings themselves (possibly with another parser).
History
Date User Action Args
2013-07-30 21:36:28paul.j3setrecipients: + paul.j3, csernazs, bethard, eric.araujo, r.david.murray, zzzeek, labrat, chris.jerdonek, nvie, DasIch, elsdoerfer, G2P, Julian, dsully, seblu, bewest, bkabrda
2013-07-30 21:36:27paul.j3setmessageid: <1375220187.96.0.244131784282.issue9253@psf.upfronthosting.co.za>
2013-07-30 21:36:27paul.j3linkissue9253 messages
2013-07-30 21:36:27paul.j3create