-
-
Notifications
You must be signed in to change notification settings - Fork 32.5k
gh-95601: restore support for awaitable objects that are not futures in asyncio.wait
#95708
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
Changes from 19 commits
88580c9
1363c9b
543c4f2
6661052
5b740df
5b974c5
c4a7237
d4dac27
cb00279
38fb812
5383116
b6ea455
980a3b9
d8354db
5f1d061
9181e25
f973c52
0430145
9189603
9c325b4
da9f2a2
7e35d9c
a5c5f4a
17cbfc9
69b2a0d
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 |
---|---|---|
|
@@ -408,19 +408,37 @@ async def wait(fs, *, timeout=None, return_when=ALL_COMPLETED): | |
when the timeout occurs are returned in the second set. | ||
""" | ||
if futures.isfuture(fs) or coroutines.iscoroutine(fs): | ||
raise TypeError(f"expect a list of futures, not {type(fs).__name__}") | ||
if not fs: | ||
raise ValueError('Set of Tasks/Futures is empty.') | ||
raise TypeError(f"expected an iterable of futures, not {type(fs).__name__}") | ||
if return_when not in (FIRST_COMPLETED, FIRST_EXCEPTION, ALL_COMPLETED): | ||
raise ValueError(f'Invalid return_when value: {return_when}') | ||
|
||
fs = set(fs) | ||
loop = events.get_running_loop() | ||
new_fs = set() | ||
|
||
for f in fs: | ||
if coroutines.iscoroutine(f): | ||
raise TypeError("Passing coroutines is forbidden, use tasks explicitly.") | ||
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. What will happened with implicitly created futures added to 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 removed the warning at @tiran 's request, with a plan to add it in a follow up PR. |
||
if not futures.isfuture(f): | ||
warnings.warn( | ||
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. Use 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. Yeah I usually would, but I kinda want to try backport the deprecation fix to 3.10 also the wording 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. @hugovk are you already working on a plan to upbraid all the existing there's a slight usability/wording concern when using it for changes in behavior instead of actual full removals in addition do you have a view on backporting deprecation, where it was clear from the code what the intention of the deprecation was, but the deprecation itself had a bug? 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'm not but that's a good idea. From a quick check, there's not too many, and most are set to be removed in 3.12 anyway.
Can you alter the wording using the
Some removals scheduled for 4.0 were from before we knew if 3.10 or 4.0 would follow 3.9 (#80480 (comment)) and in at least one case is shorthand for "sometime after 2.7.final" (#80480 (comment)). Anyway, we should review any remaining removals originally set for 4.0 (e.g. in new issues or relevant open issues) to decide if they can be removed in an upcoming 3.x.
Generally, I think it's a good idea to increase visibility and help users upgrade in time to reduce friction. It's good to ask release managers when in doubt. 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. @hugovk do you think we have enough here to make a new issue out of this side discussion. Or maybe there's two to four ideas here:
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. Sure! Or at https://discuss.python.org/? |
||
"The explicit passing of awaitable objects that are not futures " | ||
"to asyncio.wait() is deprecated since Python 3.11, and " | ||
"scheduled for removal in Python 3.14.", | ||
DeprecationWarning, | ||
stacklevel=2, | ||
) | ||
try: | ||
new_fs.add(ensure_future(f, loop=loop)) | ||
except TypeError: | ||
raise TypeError( | ||
f"An asyncio.Future was expected, got {f!r}" | ||
) from None | ||
else: | ||
new_fs.add(f) | ||
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 getting added to the set with no checks whatsoever. It needs to check 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. fixed! |
||
|
||
if any(coroutines.iscoroutine(f) for f in fs): | ||
raise TypeError("Passing coroutines is forbidden, use tasks explicitly.") | ||
if not new_fs: | ||
raise ValueError('Iterable of Tasks/Futures is empty.') | ||
|
||
loop = events.get_running_loop() | ||
return await _wait(fs, timeout, return_when, loop) | ||
return await _wait(new_fs, timeout, return_when, loop) | ||
|
||
|
||
def _release_waiter(waiter, *args): | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1 @@ | ||
The explicit passing of awaitable objects that are not :class:`asyncio.Future` to :func:`asyncio.wait` is deprecated and will be removed in version 3.14. | ||
graingert marked this conversation as resolved.
Show resolved
Hide resolved
|
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.
We cannot deprecate behaviour after beta freeze. You need a steering council or release manager exception for this unfortunately
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.
This is restoring a behaviour that was supposed to be deprecated
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.
Unfortunately, I don't follow. Could you give me some context on what happened?
Uh oh!
There was an error while loading. Please reload this page.
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.
@pablogsal from the original issue report:
This PR restores support for Awaitable objects in
asyncio.wait
which was intended to be deprecated but never threw a DeprecationWarning because of an oversight in the implementation of the deprecation