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 eric.smith
Recipients andersk, bethard, davidben, drm, eric.araujo, eric.smith, gdb, nelhage, r.david.murray
Date 2011-02-17.15:52:03
SpamBayes Score 9.068968e-12
Marked as misclassified No
Message-id <1297957927.4.0.0624155163789.issue9334@psf.upfronthosting.co.za>
In-reply-to
Content
[I doubt my terminology is exactly correct in this post, but I've tried my best to make it so.)

The more I think about this the more I realize we can't implement a parser that doesn't make guesses about '-' prefixed args and that works with arparse's existing behavior with respect to optional arguments.

For example:
parser = argparse.ArgumentParser()
parser.add_argument('--foo', nargs='?')
parser.add_argument('--bar', nargs='?')
print parser.parse_args(['--foo', '--bar', 'a'])
print parser.parse_args(['--foo', 'x', '--bar', 'a'])

Unless the parser tries to guess that --bar is an optional argument by itself, it can't know that --foo has an argument or not.

I guess it could look and say that if you called this with '--foo --baz', then '--baz' must be an argument for '--foo', but then you could never have an argument to '--foo' named '--bar', plus it all seems fragile.

Maybe this new parser (as Steven described it) wouldn't allow a variable number of arguments to optional arguments? That is, nargs couldn't be '?', '*', or '+', only a number.
History
Date User Action Args
2011-02-17 15:52:07eric.smithsetrecipients: + eric.smith, bethard, eric.araujo, r.david.murray, andersk, gdb, nelhage, drm, davidben
2011-02-17 15:52:07eric.smithsetmessageid: <1297957927.4.0.0624155163789.issue9334@psf.upfronthosting.co.za>
2011-02-17 15:52:04eric.smithlinkissue9334 messages
2011-02-17 15:52:03eric.smithcreate