Repository navigation
Document argparse.REMAINDER as being equal to "..." #68835
Description
| BPO | 24647 |
|---|---|
| Nosy | @bitdancer, @anntzer |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = <Date 2016-05-30.01:07:55.427>
created_at = <Date 2015-07-16.20:47:25.084>
labels = ['docs']
title = 'Document argparse.REMAINDER as being equal to "..."'
updated_at = <Date 2016-05-30.01:07:55.425>
user = 'https://github.com/anntzer'bugs.python.org fields:
activity = <Date 2016-05-30.01:07:55.425>
actor = 'r.david.murray'
assignee = 'docs@python'
closed = True
closed_date = <Date 2016-05-30.01:07:55.427>
closer = 'r.david.murray'
components = ['Documentation']
creation = <Date 2015-07-16.20:47:25.084>
creator = 'Antony.Lee'
dependencies = []
files = []
hgrepos = []
issue_num = 24647
keywords = []
message_count = 3.0
messages = ['246824', '247942', '266656']
nosy_count = 5.0
nosy_names = ['bethard', 'r.david.murray', 'docs@python', 'paul.j3', 'Antony.Lee']
pr_nums = []
priority = 'normal'
resolution = 'rejected'
stage = 'resolved'
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue24647'
versions = ['Python 2.7', 'Python 3.5', 'Python 3.6']
Activity
anntzer commentedon Jul 16, 2015
Currently the argparse docs mention the special values "+", "*" and "?" by their actual values instead of argparse.{ONE_OR_MORE,ZERO_OR_MORE,OPTIONAL}, but argparse.REMAINDER is mentioned as is. It seems easier to just use its actual value ("...") in the docs as well.
paulj3 commentedon Aug 3, 2015
Also, argparse.PARSER is '+...'
'? * +' have closely matched analogs in regex patterns. '...' and '+...' do not. So Python users will have an intuitive idea of what "nargs='*'" means. "nargs='...'" is not so obvious.
As a general rule, the document does not expose the values of module constants.
bitdancer commentedon May 30, 2016
I would say nargs='...' is borderline...it's meaning is *fairly* intuitive, but unlike the other three it does not, as paul.j3 points out, have a regex (or shell) counterpart.
I think we should respect the original author's decision in this case and leave well enough alone.