Author paul.j3
Recipients amcnabb, bethard, docs@python, guilherme-pg, paul.j3, r.david.murray, v+python
Date 2013-04-22.22:29:53
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1366669793.78.0.628838614105.issue14191@psf.upfronthosting.co.za>
In-reply-to
Content
The attached file has a 'parse_intermixed_args()' that has the same API as 'parse_known_args()'.

It follows the two parse step model

    args, remaining_args = optionals.parse_known_args()
    args, extras = positionals.parse_known_args(remaining_args, args)

except that the 'optionals parser' is self with the positional arguments 'deactivated' by setting their nargs to 0.  Similarly the 'positionals parser' is self with the optional arguments set to 'required=false'.

Here it is in a standalone test module illustrating its functionality and limitations.  I could provide a patch, but this form might easier to test in your own code.

When used to run test_argparse.py, it had problems in the cases where the distinction between positionals and optionals is blurred.  

For example, PARSER and REMAINDER are supposed to grab everything that follows regardless of what it looks like.  I choose to fall back on a single 'parse_know_args' call.  Raising an error would the alternative.

Similarly, a mutually exclusive group that includes a positional is difficult to handle.  Again I fall back on the single step.

So the two issues to be discussed are:

- does it provide the desired freedom to mix optionals and positionals?

- in the difficult cases, should it punt, or raise an error?
History
Date User Action Args
2013-04-22 22:29:54paul.j3setrecipients: + paul.j3, amcnabb, bethard, v+python, r.david.murray, docs@python, guilherme-pg
2013-04-22 22:29:53paul.j3setmessageid: <1366669793.78.0.628838614105.issue14191@psf.upfronthosting.co.za>
2013-04-22 22:29:53paul.j3linkissue14191 messages
2013-04-22 22:29:53paul.j3create