[issue43876] argparse documentation contrasting nargs '*' vs. '+' is misleading
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 words, nargs='+' sounds like it's distinguished from nargs='*' by virtue of implicitly making `required=True`. This implication isn't valid when the option name has a double-hyphen prefix, though: no argument parsing error is thrown for a double-hyphen-prefix-named option, even with `nargs='+'`. The docs neglect to mention this qualification that prevents `nargs='+'` from implicitly making the option required. Originally noticed while using a port of the library to R: https://github.com/trevorld/r-argparse/issues/31 -- messages: 391255 nosy: vreuter priority: normal severity: normal status: open title: argparse documentation contrasting nargs '*' vs. '+' is misleading ___ Python tracker <https://bugs.python.org/issue43876> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43876] argparse documentation contrasting nargs '*' vs. '+' is misleading
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. """ -- ___ Python tracker <https://bugs.python.org/issue43876> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43876] argparse documentation contrasting nargs '*' vs. '+' is misleading
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 docs, the distinction in the number expectation between "one or more" vs. "two or more?" What does it mean for "two or more" to be expected (for nargs='*') if there's no parse error thrown even when the option's entirely omitted? -- ___ Python tracker <https://bugs.python.org/issue43876> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43876] argparse documentation contrasting nargs '*' vs. '+' is misleading
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 prefix (hyphen(s) or not) determines whether the option's required, then it seems contradictory to have nargs='*' make a positional arg behave as if it's optional (i.e., no parse error if omitted). 2. Prefixing the option name with hyphen(s) seems to remove any distinction between `nargs='*'` and `nargs='+'` (at least without passing anything explicit about required) -- ___ Python tracker <https://bugs.python.org/issue43876> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43876] argparse documentation contrasting nargs '*' vs. '+' is misleading
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 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
<https://bugs.python.org/issue43876>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33130] functools.reduce signature/docstring discordance
New submission from Vince Reuter : 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 being italicized. -- assignee: docs@python components: Documentation messages: 314344 nosy: docs@python, vreuter priority: normal pull_requests: 5951 severity: normal status: open title: functools.reduce signature/docstring discordance type: enhancement versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue33130> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
