Vince Reuter <[email protected]> added the comment:
Looking a bit more at the examples in the "nargs" section of the argparse docs,
and on the rest of that page, I think I see the intended usage pattern
emerging. nargs='*' is only ever used on that page with an optional (by prefix)
option, or with the last positional defined. Conversely, nargs='+' (or "+") is
only used with a positional or with an optional that's paired with
action="extend".
This makes sense given the 0-or-more vs. 1-or-more distinction, but could it be
enforced by exception or by warning? Specifically, I can think of a couple
dangerous (as far as unintended consequences) cases:
1. Define a sequence of positionals with a nargs='*' sandwiched somewhere in
the middle. Then passing fewer arguments at the command-line than defined
positionals will cause the nargs='*' one to be skipped, rather than populating
truly in order. Example:
def _parse_cmdl(cmdl):
parser = argparse.ArgumentParser()
parser.add_argument("outdata", help="Path to output data file")
parser.add_argument("plotTimes", nargs='*', help="Times to plot")
parser.add_argument("outplot", help="Path to output plot file")
return parser.parse_args(cmdl)
would result in a parse of something like:
$ ./tinytest.py a b
outdata: a
plotTimes: []
outplot: b
2. Case initially presented, i.e. a nargs='+' with a hyphen-prefixed option
name. If the semantics are no different than for nargs='*', could a warning or
exception be thrown for defining something this way? It would feel safer to not
have the meaning of a value like this to nargs not be conditional on the name
of the option.
----------
_______________________________________
Python tracker <[email protected]>
<https://bugs.python.org/issue43876>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
