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 wit
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
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 a
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
New submission from Vince Reuter <vince.reu...@gmail.com>:
The signature for functools.reduce correctly refers to the collection parameter
as an iterable, but the docstring refers to it as "sequence," which the input
need not be and does not match the parameter name despite
