Skip to content

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

Merged
merged 4 commits into from
Dec 11, 2020

Conversation

nickgaya
Copy link
Contributor

@nickgaya nickgaya commented Nov 29, 2020

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

@the-knights-who-say-ni
Copy link

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 Missing

Our records indicate the following people have not signed the CLA:

@nickgaya

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
before our records are updated.

You can check yourself to see if the CLA has been received.

Thanks again for the contribution, we look forward to reviewing it!

@bedevere-bot bedevere-bot added docs Documentation in the Doc dir awaiting review labels Nov 29, 2020
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
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe async for description should be compatible with for, async with should follow with structure.

@1st1 @aeros please share your opinions.

Copy link
Member

@JulienPalard JulienPalard Dec 1, 2020

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good.

@1st1 @aeros maybe you can review the proposal?

Copy link
Member

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.

Copy link
Contributor

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.

Copy link
Contributor Author

@nickgaya nickgaya Dec 7, 2020

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.

Copy link
Contributor

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.

@aeros
Copy link
Contributor

aeros commented Dec 11, 2020

By the way, thanks for the PR and welcome @nickgaya!

@aeros aeros added the needs backport to 3.9 only security fixes label Dec 11, 2020
@aeros
Copy link
Contributor

aeros commented Dec 11, 2020

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.

@miss-islington miss-islington merged commit 4b8cdfc into python:master Dec 11, 2020
@miss-islington
Copy link
Contributor

Thanks @nickgaya for the PR 🌮🎉.. I'm working now to backport this PR to: 3.9.
🐍🍒⛏🤖

@aeros aeros added needs backport to 3.9 only security fixes and removed needs backport to 3.9 only security fixes labels Dec 11, 2020
@miss-islington
Copy link
Contributor

Thanks @nickgaya for the PR 🌮🎉.. I'm working now to backport this PR to: 3.9.
🐍🍒⛏🤖

@Mariatta Mariatta added needs backport to 3.9 only security fixes and removed needs backport to 3.9 only security fixes labels Dec 13, 2020
@miss-islington
Copy link
Contributor

Thanks @nickgaya for the PR 🌮🎉.. I'm working now to backport this PR to: 3.9.
🐍🍒⛏🤖

@bedevere-bot bedevere-bot removed the needs backport to 3.9 only security fixes label Dec 13, 2020
@bedevere-bot
Copy link

GH-23749 is a backport of this pull request to the 3.9 branch.

miss-islington pushed a commit to miss-islington/cpython that referenced this pull request Dec 13, 2020
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>
miss-islington added a commit that referenced this pull request Dec 13, 2020
… (GH-23749)

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>
adorilson pushed a commit to adorilson/cpython that referenced this pull request Mar 13, 2021
Fix the wording in the documentation of `async for` to correctly describe asynchronous iterables.  This fix is relevant for version 3.7 onward.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docs Documentation in the Doc dir skip news
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants