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 paul.j3
Recipients amcnabb, bethard, docs@python, guilherme-pg, paul.j3, r.david.murray, v+python
Date 2013-03-29.20:56:13
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1364590574.24.0.02037954914.issue14191@psf.upfronthosting.co.za>
In-reply-to
Content
Glenn
I looked at your t18a.py test case

    parser = ArgumentParser()
    parser.add_argument('--foo', dest='foo')
    parser.add_argument('--bar', dest='bar')
    parser.add_argument('foz')
    parser.add_argument('baz', nargs='*')

and parse variations on 'a b c d --foo x --bar 1'

I think your main problem is with the 'baz', nargs='*'.  If nargs was changed to '+', 'a --foo x b c d --bar 1' would work, returning {foz='a', bar=['b','c','d']}.

argparse alternates between consuming positional and optionals until it runs out of arguments or argument strings.  But with '*', both 'foz' and 'baz' are consumed with the first set of positional strings {foz='a', baz=[]}.  When it gets to 'b c d' there are no more positional arguments to consume, so they get put into 'extras'.

With nargs='+', 'a b --foo x c d --bar 1' would assign {foz='a', baz=[b]}, and extras=['c','d'].

So while optionals can be interspersed with positionals, they can't be placed within the set of strings intended for one positional. That seems to me to very reasonable (why break up 'b c d'?).  And as your file demonstrates, you can fall back on parse_known_args to handle the extras.
History
Date User Action Args
2013-03-29 20:56:14paul.j3setrecipients: + paul.j3, amcnabb, bethard, v+python, r.david.murray, docs@python, guilherme-pg
2013-03-29 20:56:14paul.j3setmessageid: <1364590574.24.0.02037954914.issue14191@psf.upfronthosting.co.za>
2013-03-29 20:56:14paul.j3linkissue14191 messages
2013-03-29 20:56:13paul.j3create