Vince Reuter <vreu...@protonmail.com> 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 <rep...@bugs.python.org>
<https://bugs.python.org/issue43876>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to