Skip to content
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

bpo-39386: Prevent double awaiting of async iterator #18081

Merged
merged 1 commit into from Jan 20, 2020

Conversation

@asvetlov
Copy link
Contributor

asvetlov commented Jan 20, 2020

@asvetlov

This comment has been minimized.

Copy link
Contributor Author

asvetlov commented Jan 20, 2020

@1st1 would be very nice if you can find time for the PR review.

@asvetlov

This comment has been minimized.

Copy link
Contributor Author

asvetlov commented Jan 20, 2020

@njsmith I appreciate your review as well

@1st1
1st1 approved these changes Jan 20, 2020
@1st1

This comment has been minimized.

Copy link
Member

1st1 commented Jan 20, 2020

LGTM, Andrew. Thank you.

@asvetlov asvetlov merged commit a96e06d into python:master Jan 20, 2020
9 checks passed
9 checks passed
Docs
Details
Windows (x86)
Details
Windows (x64)
Details
macOS
Details
Ubuntu
Details
Azure Pipelines PR #20200120.18 succeeded
Details
bedevere/issue-number Issue number 39386 found
Details
bedevere/news News entry found in Misc/NEWS.d
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@asvetlov asvetlov deleted the asvetlov:prevent-double-await-of-async-gen branch Jan 20, 2020
@miss-islington

This comment has been minimized.

Copy link

miss-islington commented Jan 20, 2020

Thanks @asvetlov for the PR 🌮🎉.. I'm working now to backport this PR to: 3.7, 3.8.
🐍🍒🤖

@bedevere-bot

This comment has been minimized.

Copy link

bedevere-bot commented Jan 20, 2020

GH-18086 is a backport of this pull request to the 3.8 branch.

miss-islington added a commit to miss-islington/cpython that referenced this pull request Jan 20, 2020
(cherry picked from commit a96e06d)

Co-authored-by: Andrew Svetlov <andrew.svetlov@gmail.com>
miss-islington added a commit to miss-islington/cpython that referenced this pull request Jan 20, 2020
(cherry picked from commit a96e06d)

Co-authored-by: Andrew Svetlov <andrew.svetlov@gmail.com>
@bedevere-bot

This comment has been minimized.

Copy link

bedevere-bot commented Jan 20, 2020

GH-18087 is a backport of this pull request to the 3.7 branch.

@asvetlov

This comment has been minimized.

Copy link
Contributor Author

asvetlov commented Jan 20, 2020

Thanks for the review, @njsmith and @1st1

Copy link
Member

aeros left a comment

Would it be redundant to explicitly test asend() as well?

For example:

     def test_async_gen_await_asend_twice(self):
         async def async_iterate():
             yield 1
             yield 2
  
         async def run():
             it = async_iterate()
             nxt = it.asend(None)
             await nxt
             with self.assertRaisesRegex(
                      RuntimeError,
                      r"cannot reuse already awaited __anext__\(\)/asend\(\)"
              ):
                  await nxt
  
         self.loop.run_until_complete(run())

This seems effectively covered by test_async_gen_await_anext_twice, but I don't think it hurts to include both (especially since it's straightforward and a quick test).

Otherwise, LGTM.

@aeros

This comment has been minimized.

Copy link
Member

aeros commented Jan 20, 2020

Oh oops, looks like I was typing that just as it was being reviewed by Yury, never mind.

@asvetlov

This comment has been minimized.

Copy link
Contributor Author

asvetlov commented Jan 20, 2020

@aeros sorry, I've pressed "Merge" button before reading your message.
New tests don't hurt, and they should be pretty fast.
I would say that both __anext__ and asend are processed by single async_gen_asend_send function, so tests doubling is redundant a little.

@aeros

This comment has been minimized.

Copy link
Member

aeros commented Jan 20, 2020

@asvetlov No worries! It was more of an afterthought than anything, and I don't think it will have a significant impact on the long-term stability if we don't include the explicit asend() test. As you said, both __anext__ and asend are handled by the same C-API function, I doubt that would realistically end up changing at any point in the future.

miss-islington added a commit that referenced this pull request Jan 20, 2020
(cherry picked from commit a96e06d)

Co-authored-by: Andrew Svetlov <andrew.svetlov@gmail.com>
miss-islington added a commit that referenced this pull request Jan 20, 2020
(cherry picked from commit a96e06d)

Co-authored-by: Andrew Svetlov <andrew.svetlov@gmail.com>
petdance added a commit to petdance/cpython that referenced this pull request Jan 21, 2020
petdance added a commit to petdance/cpython that referenced this pull request Jan 21, 2020
petdance added a commit to petdance/cpython that referenced this pull request Jan 21, 2020
petdance added a commit to petdance/cpython that referenced this pull request Jan 21, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.