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 v+python
Recipients bethard, guilherme-pg, v+python
Date 2012-03-09.01:35:46
SpamBayes Score 2.7755576e-16
Marked as misclassified No
Message-id <1331256949.97.0.294931268494.issue14191@psf.upfronthosting.co.za>
In-reply-to
Content
*Very* interesting, Steven.

Looking again at section 15.4.6, and recognizing that positional arguments were never parsed by optparse, then we discover that with two minor tweaks, removing "and add additional ArgumentParser.add_argument() calls for the positional arguments." from step two, and calling parse_known_args instead of parse_args, we actually achieve greater compatibility with optparse, for those that need it.

However, the above would allow undefined arguments to slip through into the positional arguments.

So to prevent that, the second parser you suggest, defining only the positional arguments, will tighten up the error checks.

So this issue could be resolved simply by updating section 15.4.6 of the documentation to explain all this.  On the other hand, the explanation gets long and perhaps confusing.


Looking at the 15.4.4, I see:

ArgumentParser.parse_args(args=None, namespace=None)

    Convert argument strings to objects and assign them as attributes of the namespace. Return the populated namespace.

    Previous calls to add_argument() determine exactly what objects are created and how they are assigned. See the documentation for add_argument() for details.

    By default, the argument strings are taken from sys.argv, and a new empty Namespace object is created for the attributes.


However, nowhere is the args= parameter explained.  One example is given at the end of 15.4.4.6 showing the use of args= which apparently accepts a list of parameters, similar to the positional list of parameters that are used in all the other examples.  It might be nice to clarify that.


This leads into a suggestion: a new keyword parameter for  parse_args: intermixed=False.

When False, the default, new_parse_args would act exactly as it does today, possibly by calling old_parse_args.  When True, parse_args would implement your suggestion probably in the following way: filter out the positional parameters, call parse_known_args, then filter out the optional parameters, call old_parse_args, and return the combination.

t16.py implements this, external to the class, and using two parsers as you suggested.

One thing I notice in playing with my optparse function, is that error messages contain an improper usage message.  This would seem to be most easily fixed if the logic were built in to argparse, rather than attempting to do it externally.

Adding this parameter would also make it is much easier to write section 15.4.7 accurately, and would reduce the porting burden on each implementer, as well.  The technique has merit in achieving compatibility with optparse, to allow it to remain deprecated, and looks straightforward to implement.
History
Date User Action Args
2012-03-09 01:35:50v+pythonsetrecipients: + v+python, bethard, guilherme-pg
2012-03-09 01:35:49v+pythonsetmessageid: <1331256949.97.0.294931268494.issue14191@psf.upfronthosting.co.za>
2012-03-09 01:35:49v+pythonlinkissue14191 messages
2012-03-09 01:35:47v+pythoncreate