paul j3 added the comment:
Let's see if I can clarify somethings. But first, I should say that I've
worked with this code for so long, that I may miss things that could confuse a
beginner.
A basic distinction is between "optionals" and "positionals". I put those in
quotes because that's
Vince Reuter 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
Vince Reuter added the comment:
There are two small related issues, but I'm not sure how they relate and/or if
they've been addressed previously, so I'm sorry for duplicate messaging if
that's the case.
1. If it's the case that absent an explicit `required=` statement, the
option name
Vince Reuter added the comment:
Got it, I see. I guess I'd prefer to be able to control the expectation about
argument number through the keyword, without changing the option name, but I
understand if the other way (as implemented) is preferred. Can you clarify,
though, or direct me in the
Raymond Hettinger added the comment:
For me, it is the opposite. I would have been completely surprised if setting
nargs caused an optional argument to become required.
The "nargs" parameter is entirely about the number of data arguments, not about
the option itself. When nargs=1, then
Vince Reuter added the comment:
Here's the docs excerpt that seems misleading:
"""
'+'. Just like '*', all command-line args present are gathered into a list.
Additionally, an error message will be generated if there wasn’t at least one
command-line argument present.
"""
--
New submission from Vince Reuter :
Standard library docs for argparse, at
https://docs.python.org/3/library/argparse.html#nargs, suggest that setting
nargs='+' differs from nargs='*' in that the former will raise a parsing error
when the argument's omitted while the latter will not. In other
