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.27486e-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.
History
Date User Action Args
2011-03-26 18:11:02andersksetrecipients: + andersk, bethard, eric.smith, eric.araujo, r.david.murray, gdb, nelhage, drm, davidben
2011-03-26 18:11:02andersksetmessageid: <1301163062.06.0.457703774384.issue9334@psf.upfronthosting.co.za>
2011-03-26 18:11:01andersklinkissue9334 messages
2011-03-26 18:11:01anderskcreate