-
-
Notifications
You must be signed in to change notification settings - Fork 32.1k
gh-133438: Fix the use of the terms "argument" and "parameter" in the documentation #135160
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
6a95300
0f032ab
7246fcf
8516800
4f33f9e
e97232a
86550eb
b8c621c
a6ac9e5
52dcd2a
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
@@ -410,8 +410,8 @@ inside nested parentheses. They are: | |||||||||
|
||||||||||
``$`` | ||||||||||
:c:func:`PyArg_ParseTupleAndKeywords` only: | ||||||||||
Indicates that the remaining arguments in the Python argument list are | ||||||||||
keyword-only. Currently, all keyword-only arguments must also be optional | ||||||||||
Indicates that the remaining arguments in the Python argument list can be | ||||||||||
supplied only by keyword. Currently, all such arguments must also be optional | ||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sadly, “keyword” means something entirely different. IMO we need to use the full term.
Suggested change
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is from the definition of the keyword-only parameter. * :dfn:`keyword-only`: specifies an argument that can be supplied only
by keyword. Keyword-only parameters can be defined by including a There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. In the context of
Suggested change
The |
||||||||||
arguments, so ``|`` must always be specified before ``$`` in the format | ||||||||||
string. | ||||||||||
|
||||||||||
|
@@ -450,7 +450,7 @@ API Functions | |||||||||
|
||||||||||
.. c:function:: int PyArg_ParseTuple(PyObject *args, const char *format, ...) | ||||||||||
|
||||||||||
Parse the parameters of a function that takes only positional parameters into | ||||||||||
Parse the arguments of a function that takes only positional arguments into | ||||||||||
local variables. Returns true on success; on failure, it returns false and | ||||||||||
raises the appropriate exception. | ||||||||||
|
||||||||||
|
@@ -463,8 +463,8 @@ API Functions | |||||||||
|
||||||||||
.. c:function:: int PyArg_ParseTupleAndKeywords(PyObject *args, PyObject *kw, const char *format, char * const *keywords, ...) | ||||||||||
|
||||||||||
Parse the parameters of a function that takes both positional and keyword | ||||||||||
parameters into local variables. | ||||||||||
Parse the arguments of a function that takes both positional and keyword | ||||||||||
arguments into local variables. | ||||||||||
The *keywords* argument is a ``NULL``-terminated array of keyword parameter | ||||||||||
names specified as null-terminated ASCII or UTF-8 encoded C strings. | ||||||||||
Empty names denote | ||||||||||
|
@@ -506,7 +506,7 @@ API Functions | |||||||||
|
||||||||||
.. c:function:: int PyArg_Parse(PyObject *args, const char *format, ...) | ||||||||||
|
||||||||||
Parse the parameter of a function that takes a single positional parameter | ||||||||||
Parse the argument of a function that takes a single positional argument | ||||||||||
into a local variable. Returns true on success; on failure, it returns | ||||||||||
false and raises the appropriate exception. | ||||||||||
|
||||||||||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -1634,7 +1634,7 @@ method. Since then, Python has gained two new formatting approaches: | |
|
||
Logging (as of 3.2) provides improved support for these two additional | ||
formatting styles. The :class:`Formatter` class been enhanced to take an | ||
additional, optional keyword parameter named ``style``. This defaults to | ||
additional, optional keyword argument named ``style``. This defaults to | ||
Comment on lines
1636
to
+1637
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think an alternative change, not necessarily better, would have been /take/have/. |
||
``'%'``, but other possible values are ``'{'`` and ``'$'``, which correspond | ||
to the other two formatting styles. Backwards compatibility is maintained by | ||
default (as you would expect), but by explicitly specifying a style parameter, | ||
|
@@ -1675,10 +1675,10 @@ That can still use %-formatting, as shown here:: | |
>>> | ||
|
||
Logging calls (``logger.debug()``, ``logger.info()`` etc.) only take | ||
positional parameters for the actual logging message itself, with keyword | ||
parameters used only for determining options for how to handle the actual | ||
logging call (e.g. the ``exc_info`` keyword parameter to indicate that | ||
traceback information should be logged, or the ``extra`` keyword parameter | ||
positional arguments for the logging message itself, with keyword | ||
arguments used only for determining options for how to handle the actual | ||
logging call (e.g. the ``exc_info`` keyword argument to indicate that | ||
traceback information should be logged, or the ``extra`` keyword argument | ||
to indicate additional contextual information to be added to the log). So | ||
you cannot directly make logging calls using :meth:`str.format` or | ||
:class:`string.Template` syntax, because internally the logging package | ||
|
@@ -2732,10 +2732,10 @@ governs the formatting of logging messages for final output to logs, and is | |
completely orthogonal to how an individual logging message is constructed. | ||
|
||
Logging calls (:meth:`~Logger.debug`, :meth:`~Logger.info` etc.) only take | ||
positional parameters for the actual logging message itself, with keyword | ||
parameters used only for determining options for how to handle the logging call | ||
(e.g. the ``exc_info`` keyword parameter to indicate that traceback information | ||
should be logged, or the ``extra`` keyword parameter to indicate additional | ||
positional arguments for the logging message itself, with keyword | ||
arguments used only for determining options for how to handle the logging call | ||
(e.g. the ``exc_info`` keyword argument to indicate that traceback information | ||
should be logged, or the ``extra`` keyword argument to indicate additional | ||
contextual information to be added to the log). So you cannot directly make | ||
logging calls using :meth:`str.format` or :class:`string.Template` syntax, | ||
because internally the logging package uses %-formatting to merge the format | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -232,7 +232,7 @@ Scheduling callbacks | |
Callbacks are called in the order in which they are registered. | ||
Each callback will be called exactly once. | ||
|
||
The optional keyword-only *context* argument specifies a | ||
The optional keyword argument *context* specifies a | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why remove "only"? I don't see anything wrong with calling these "keyword-only". There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Answering my own question after reading more of the diff: "only" means nothing for arguments, since an argument is only ever keyword or positional, not both. So arguments are either positional or keyword; "keyword-only" makes sense only for parameters because parameters can be both at once. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. IMO, the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If the parameter was keyword-or-positional, we would say "The optional argument context". There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I agree with Jelle's 2nd comment that |
||
custom :class:`contextvars.Context` for the *callback* to run in. | ||
Callbacks use the current context when no *context* is provided. | ||
|
||
|
@@ -296,11 +296,11 @@ clocks to track time. | |
scheduled for exactly the same time, the order in which they | ||
are called is undefined. | ||
|
||
The optional positional *args* will be passed to the callback when | ||
The optional positional arguments *args* will be passed to the callback when | ||
it is called. If you want the callback to be called with keyword | ||
arguments use :func:`functools.partial`. | ||
|
||
An optional keyword-only *context* argument allows specifying a | ||
An optional keyword argument *context* allows specifying a | ||
custom :class:`contextvars.Context` for the *callback* to run in. | ||
The current context is used when no *context* is provided. | ||
|
||
|
@@ -377,11 +377,11 @@ Creating Futures and Tasks | |
If the *name* argument is provided and not ``None``, it is set as | ||
the name of the task using :meth:`Task.set_name`. | ||
|
||
An optional keyword-only *context* argument allows specifying a | ||
An optional keyword argument *context* allows specifying a | ||
custom :class:`contextvars.Context` for the *coro* to run in. | ||
The current context copy is created when no *context* is provided. | ||
|
||
An optional keyword-only *eager_start* argument allows specifying | ||
An optional keyword argument *eager_start* allows specifying | ||
if the task should execute eagerly during the call to create_task, | ||
or be scheduled later. If *eager_start* is not passed the mode set | ||
by :meth:`loop.set_task_factory` will be used. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the old wording is clearer here, "keyword-only" is a well-known term in Python.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Keyword-only can be only parameters. Arguments are either positional or keyword. Argument is what we pass to the function.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the same way, an argument can't be optional: if you omit it, it does not exist at all.
But the terms “optional” and “keyword-only” describe the possibilities you have, not a specific argument in a specific call.