Message132260
| Author |
andersk |
| Recipients |
andersk, bethard, davidben, drm, eric.araujo, eric.smith, gdb, nelhage, r.david.murray |
| Date |
2011年03月26日.18:11:01 |
| SpamBayes Score |
2.2748635e-08 |
| Marked as misclassified |
No |
| Message-id |
<1301163062.06.0.457703774384.issue9334@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
> @andersk: Would the restriction to only having flags with a fixed
> number of arguments be acceptable for your use case?
I think that’s fine. Anyone coming from optparse won’t need options with optional arguments.
However, FWIW, GNU getopt_long() supports options with an optional argument under the restrictions that:
• the option must be a long option,
• the optional argument must be the only argument for the option, and
• the argument, if present, must be supplied using the
‘--option=argument’ form, not the ‘--option argument’ form.
This avoids all parsing ambiguity. It would be useful to have feature parity with getopt_long(), to facilitate writing Python wrapper scripts for C programs. |
|