-
-
Notifications
You must be signed in to change notification settings - Fork 32.1k
bpo-41879: Doc: Fix description of async for statement #23548
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
Conversation
Hello, and thanks for your contribution! I'm a bot set up to make sure that the project can legally accept this contribution by verifying everyone involved has signed the PSF contributor agreement (CLA). CLA MissingOur records indicate the following people have not signed the CLA: For legal reasons we need all the people listed to sign the CLA before we can look at your contribution. Please follow the steps outlined in the CPython devguide to rectify this issue. If you have recently signed the CLA, please wait at least one business day You can check yourself to see if the CLA has been received. Thanks again for the contribution, we look forward to reviewing it! |
Doc/reference/compound_stmts.rst
Outdated
An :term:`asynchronous iterable` is able to call asynchronous code in its | ||
*iter* implementation, and :term:`asynchronous iterator` can call asynchronous | ||
code in its *next* method. | ||
An :term:`asynchronous iterable` provides an *iter* method that returns an |
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.
Technically *iter*
is __aiter__
and *next*
is __anext__
.
I have no idea how to write the text better. Maybe it should not name iter/next at all but define async-iterable/async-iterator in plain English words?
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 agree it's a bit unclear, but consistent with how async context managers are described in the async with
section.
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.
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.
Beware english not my primary language, but here's my proposed wording:
An :term:`asynchronous iterable` provides an ``__aiter__`` method that directly returns an
:term:`asynchronous iterator`, which can call asynchronous code in its ``async __anext__``
method.
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.
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 like Julien's phrasing.
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.
+1 from me to go with Julian's proposal.
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'm not too keen on this change as I think the reason for using italicized words originally was to refer to the methods without getting into the specifics, which are described in more detail in the data model documentation for asynchronous iterators. Compare to the async with
section, which introduces the concept of an asynchronous context manager as "a context manager that is able to suspend execution in its enter and exit methods" rather than using the exact names.
However Julien's proposal seems to have majority support so I updated the PR accordingly.
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.
The reference section of the docs is typically intended to be more technically accurate, rather than prioritizing a simplified introduction. I wouldn't be opposed to applying the same to async with
(to instead refer to __aexit__
and __aenter__
), but don't think it's worth changing by itself.
By the way, thanks for the PR and welcome @nickgaya! |
Adding backport label only for 3.9, as it's the latest version present on docs.python.org. I typically don't backport lower than that for documentation PRs, since there's minimal to no benefit for most users. |
Thanks @nickgaya for the PR 🌮🎉.. I'm working now to backport this PR to: 3.9. |
Thanks @nickgaya for the PR 🌮🎉.. I'm working now to backport this PR to: 3.9. |
Thanks @nickgaya for the PR 🌮🎉.. I'm working now to backport this PR to: 3.9. |
GH-23749 is a backport of this pull request to the 3.9 branch. |
Fix the wording in the documentation of `async for` to correctly describe asynchronous iterables. This fix is relevant for version 3.7 onward. (cherry picked from commit 4b8cdfc) Co-authored-by: Nick Gaya <nicholasgaya+github@gmail.com>
Fix the wording in the documentation of `async for` to correctly describe asynchronous iterables. This fix is relevant for version 3.7 onward.
Fix the wording in the documentation of
async for
to correctly describe asynchronous iterables. This fix is relevant for version 3.7 onward.https://bugs.python.org/issue41879
Automerge-Triggered-By: GH:aeros