Message155272
Sad. That means all the documentation of workarounds needs to be written, even figured out in the first place. Steven's code, while being a nice implementation when proper arguments are provided, produces inappropriate errors, because only the positional, or only the optional, parameters are printed when errors occur.
So it would probably take a third parser, with all the parameters defined, to exist, to allow easiest generation of the usage message, but I'm not quite sure how to catch the error printing, and redirect it to the third parser.
So, I tried the classes in t17.py; they are not complete; CompatibleArgumentParser should pass through all the other APIs, and I'm not sure if all the extension semantics can be appropriately passed through when there are three classes and two objects involved. But this is sort of a proof-of-concept wrapper for achieving intermixed optional and positional arguments, and still get proper error messages. |
|
Date |
User |
Action |
Args |
2012-03-10 00:04:12 | v+python | set | recipients:
+ v+python, bethard, r.david.murray, docs@python, guilherme-pg |
2012-03-10 00:04:12 | v+python | set | messageid: <1331337852.08.0.696657544384.issue14191@psf.upfronthosting.co.za> |
2012-03-10 00:04:11 | v+python | link | issue14191 messages |
2012-03-10 00:04:11 | v+python | create | |
|