Message155039
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. |
|
Date |
User |
Action |
Args |
2012-03-06 22:04:45 | v+python | set | recipients:
+ v+python, bethard, guilherme-pg |
2012-03-06 22:04:45 | v+python | set | messageid: <1331071485.22.0.769678692488.issue14191@psf.upfronthosting.co.za> |
2012-03-06 22:04:44 | v+python | link | issue14191 messages |
2012-03-06 22:04:44 | v+python | create | |
|