[issue15990] solidify argument/parameter terminology

Roundup Robot added the comment: New changeset ecf3cd3af502 by Chris Jerdonek in branch '2.7': Add additional links and index entries for "argument" and "parameter". http://hg.python.org/cpython/rev/ecf3cd3af502 New changeset 31e1f0b7f42e by Chris Jerdonek in branch '3.2': Add additional links a

[issue15990] solidify argument/parameter terminology

Changes by Chris Jerdonek : -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed ___ Python tracker ___ _

[issue15990] solidify argument/parameter terminology

Roundup Robot added the comment: New changeset f44b8d69e5fc by Chris Jerdonek in branch '2.7': Backport from 3.2: improve argument/parameter documentation (issue #15990). http://hg.python.org/cpython/rev/f44b8d69e5fc -- nosy: +python-dev ___ Python tr

[issue15990] solidify argument/parameter terminology

Chris Jerdonek added the comment: Attaching a 2.7 version of the patch for this issue. >From the patch committed to Python 3, I removed mention of keyword-only >parameters, inspect.Parameter, and PEP 362 (because all are specific to Python >3). -- Added file: http://bugs.python.org/fi

[issue15990] solidify argument/parameter terminology

Chris Jerdonek added the comment: I just created issue 16574 to clarify PEP 1 with regard to the above. -- ___ Python tracker ___ ___

[issue15990] solidify argument/parameter terminology

Chris Jerdonek added the comment: Thanks for the clarification. I will create an issue to clarify that part of PEP 1. It should also say who is allowed to make such changes and whether/from whom approval is necessary, etc. -- ___ Python tracker <

[issue15990] solidify argument/parameter terminology

Ezio Melotti added the comment: The PEPs don't undergo major changes, but AFAIU typo fixes and minor clarifications/rephrasing are allowed. -- ___ Python tracker ___ ___

[issue15990] solidify argument/parameter terminology

Éric Araujo added the comment: PEP 1 doesn’t reflect current practice then. -- ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue15990] solidify argument/parameter terminology

Chris Jerdonek added the comment: > Note that I took this from the pep. The pep could get the same clarification > (unless I made it more confusing than it was). Reading the following, it seems that PEPs aren't generally clarified after becoming Final (as is PEP 362): "In general, Standards t

[issue15990] solidify argument/parameter terminology

Changes by Guido van Rossum : -- nosy: -gvanrossum, python-dev ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue15990] solidify argument/parameter terminology

Chris Jerdonek added the comment: I realize now that this would also be good for 2.7. I will try to do that tomorrow. -- versions: +Python 2.7, Python 3.2 ___ Python tracker __

[issue15990] solidify argument/parameter terminology

Roundup Robot added the comment: New changeset 69d5d834c5cb by Chris Jerdonek in branch '3.2': Improve argument/parameter documentation (issue #15990). http://hg.python.org/cpython/rev/69d5d834c5cb New changeset 40fd26a4206b by Chris Jerdonek in branch '3.3': Merge from 3.2: improve argument/par

[issue15990] solidify argument/parameter terminology

Chris Jerdonek added the comment: For some reason, Rietveld is erroring out every time I try to reply to one of the comments. So I am pasting the reply below: [Issue in the Rietveld tracker here: http://code.google.com/p/rietveld/issues/detail?id=394 ] On 2012/11/26 22:07:50, ezio.melotti wr

[issue15990] solidify argument/parameter terminology

Chris Jerdonek added the comment: Attaching new patch to address Ezio's suggestions on Rietveld. I will also respond to those comments on Rietveld shortly. -- Added file: http://bugs.python.org/file28142/issue-15990-5-default.patch ___ Python tracke

[issue15990] solidify argument/parameter terminology

Chris Jerdonek added the comment: I'm attaching a patch that preserves the structure of the previous patch but that builds on the wording and formatting. The patch also addresses many of the comments on Rietveld. I will also publish some comment replies on Rietveld (to the previous patch) th

[issue15990] solidify argument/parameter terminology

Chris Jerdonek added the comment: I have a number of comments but it is a holiday this weekend so I might not be able to get to it for a day or two. -- ___ Python tracker ___ __

[issue15990] solidify argument/parameter terminology

Ezio Melotti added the comment: I modified the last patch to use bullet lists and include more examples, and also added a FAQ entry to explain the difference between args and parameters. I'll leave further comments on rietveld. -- nosy: +eric.araujo Added file: http://bugs.python.org/fi

[issue15990] solidify argument/parameter terminology

Chris Jerdonek added the comment: I like option (3). I attached a new patch using this approach. As suggested, I made the glossary entries for "keyword argument" and "positional argument" into stubs. So now there are just two substantive entries: one for "argument" and one for "parameter."

[issue15990] solidify argument/parameter terminology

Ezio Melotti added the comment: On one hand it's good to have individual entries that can be referenced. On the other hand I think it's important that people get the full picture, and having these definitions sparse in 4 or more distinct glossary entries doesn't help IMHO -- even if the reader

[issue15990] solidify argument/parameter terminology

Chris Jerdonek added the comment: Here is a proposed patch just to get the ball rolling on this. Note that I'm proposing that we let ourselves use the word "standard" in place of "positional-or-keyword" when talking about parameters. This is partly inspired by PEP 362, which says, "Parameter.

[issue15990] solidify argument/parameter terminology

Chris Jerdonek added the comment: > IMHO as soon as you use terms like "receives" or "accepts", you are still > talking about arguments. Even PEP 362 is loose with its language in this regard. For example, at the beginning of the "Signature Object" section: "For each parameter accepted by th

[issue15990] solidify argument/parameter terminology

Chris Jerdonek added the comment: We could start by establishing the argument/parameter distinction in the glossary. Currently, the word "parameter" does not appear in the glossary, and the definition of "argument" blurs the distinction between the two: For example, in the following definitio

[issue15990] solidify argument/parameter terminology

Mark Dickinson added the comment: Nick Coghlan pointed out that a lot of this discussion has already happened for the function signature object PEP [1]. That PEP defines constants Parameter.POSITIONAL_ONLY Parameter.POSITIONAL_OR_KEYWORD Parameter.KEYWORD_ONLY Parameter.VAR_POS

[issue15990] solidify argument/parameter terminology

Ezio Melotti added the comment: > "between arguments (what you pass, call syntax) and parameters > (what the function receives, function definition syntax)" Note that there's a subtle difference to make here. IMHO as soon as you use terms like "receives" or "accepts", you are still talking abo

[issue15990] solidify argument/parameter terminology

Changes by Arfrever Frehtes Taifersar Arahesis : -- nosy: +Arfrever ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue15990] solidify argument/parameter terminology

Changes by Terry J. Reedy : -- nosy: +terry.reedy ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.p

[issue15990] solidify argument/parameter terminology

Changes by Ezio Melotti : -- nosy: +ezio.melotti type: -> enhancement ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubs

[issue15990] solidify argument/parameter terminology

Changes by Mark Dickinson : -- nosy: +mark.dickinson ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mai

[issue15990] solidify argument/parameter terminology

New submission from Chris Jerdonek: There is currently some ambiguity in our documentation around positional and keyword arguments (e.g. whether positional means "position-only" or "non-keyword" (roughly) and whether various terms and definitions should be for the calling syntax or the functio