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-04-22.22:29:53
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
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, 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?
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: <>
2013-04-22 22:29:53paul.j3linkissue14191 messages
2013-04-22 22:29:53paul.j3create