Repository navigation
asyncio.wait should accept generator of tasks as first argument #78530
Description
| BPO | 34349 |
|---|---|
| Nosy | @asvetlov, @1st1, @jnwatson, @tirkarthi, @epiphyte |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = None
created_at = <Date 2018-08-06.19:41:06.692>
labels = ['3.8', 'expert-asyncio']
title = 'asyncio.wait should accept generator of tasks as first argument'
updated_at = <Date 2018-08-07.14:20:15.310>
user = 'https://github.com/jnwatson'bugs.python.org fields:
activity = <Date 2018-08-07.14:20:15.310>
actor = 'yselivanov'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['asyncio']
creation = <Date 2018-08-06.19:41:06.692>
creator = 'jnwatson'
dependencies = []
files = []
hgrepos = []
issue_num = 34349
keywords = []
message_count = 2.0
messages = ['323217', '323241']
nosy_count = 5.0
nosy_names = ['asvetlov', 'yselivanov', 'jnwatson', 'xtreak', 'epiphyte']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = None
url = 'https://bugs.python.org/issue34349'
versions = ['Python 3.8']Linked PRs
Metadata
Metadata
Assignees
Projects
- Status
Activity
jnwatson commented on Aug 6, 2018
Currently, passing a generator of coroutines or futures as the first parameter of asyncio.wait raises a TypeError. This is in conflict with the documentation calling the first parameter a "sequence".
Line in question. https://github.com/python/cpython/blob/3.7/Lib/asyncio/tasks.py#L347
Generators are indeed coroutines, so the check to validate that the first parameter is not a coroutine or a future is too specific.
I'd suggest replacing that line with a check that the passed-in parameter is iterable, i.e. hasattr(futures, __iter__).
1st1 commented on Aug 7, 2018
Since we're deprecating generator-based coroutines anyways, I too think that the check can be relaxed.
kumaraditya303 commented on Dec 2, 2022
Since generator based coroutines are gone, I think we should relax this check and allow generators.
JelleZijlstra commented on Dec 2, 2022
Allowing generators in 3.12 seems like a good idea. It's probably also useful to change the documentation in 3.10 and 3.11 to clarify that generators don't work, as #99936 asked for.
kumaraditya303 commented on Dec 8, 2022
Let's do it.
gvanrossum commented on Dec 22, 2022
So there are two separate tasks here, right:
gvanrossum commented on Mar 17, 2023
According to GH, the PR will close this issue. But it should remain open until the 3.10/3.11 docs are also updated.
GH-78530: add support for generators in `asyncio.wait` (#102761)
Merge branch 'main' into inlinecomp2
pythonGH-78530: add support for generators in `asyncio.wait` (python#…
pythonGH-78530: add support for generators in `asyncio.wait` (python#…
[3.11] GH-78530: clarify docs for generators yielding tasks in `async…
kumaraditya303 commented on Apr 24, 2023
Fixed by #103748