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-06.22:04:43
SpamBayes Score 6.313209e-06
Marked as misclassified No
Message-id <1331071485.22.0.769678692488.issue14191@psf.upfronthosting.co.za>
In-reply-to
Content
Interesting that the behavior is intentional, yet it accepts positional parameters either before, or after, or between optional (flag) parameters.

This seems to me to be a case where proper documentation of the intention would have led to the realization that it is easier to fix the code than the documentation.

The only definition of positional parameters I could find in the present documentation is:

When parse_args() is called, optional arguments will be identified by the - prefix, and the remaining arguments will be assumed to be positional:

This is simple and succinct, but leads to my interpretation that they can be anywhere, intermixed with optional arguments.

Further, optparse, which argparse attempts to replace, permitted positional arguments to be intermixed with optional arguments, see new file t13.py which demonstrates that.

To document that positional parameters must be grouped together, yet can appear anywhere, the documentation would have to get much more verbose...  something like

All positional parameters must be grouped together in a single sequence.  However, that group of parameters may have optional parameters either before it or after it, or there may be optional parameter both before it and after it.
History
Date User Action Args
2012-03-06 22:04:45v+pythonsetrecipients: + v+python, bethard, guilherme-pg
2012-03-06 22:04:45v+pythonsetmessageid: <1331071485.22.0.769678692488.issue14191@psf.upfronthosting.co.za>
2012-03-06 22:04:44v+pythonlinkissue14191 messages
2012-03-06 22:04:44v+pythoncreate