This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author André Caron
Recipients André Caron, gvanrossum, vstinner, yselivanov
Date 2016-02-13.21:17:52
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
When the asyncio.wait() function with coroutine objects as inputs, it is impossbible to extract the results reliably.

This issue arises because asyncio.wait() returns an unordered set of futures against which membership tests of coroutine objects always fail.

The issue is made even worse by the fact that coroutine objects cannot be awaited multiple times (see  Any await expression on the coroutine object after the call to asyncio.wait() returns None, regardless of the coroutine's return value.

  (See attached `` for an example of both these issues.)

In the worst case, multiple inputs are coroutine objects and the set of returned futures contains return values but there is no way to determine which result corresponds to which coroutine call.

To work around this issue, callers need to explicitly use asyncio.ensure_future() on coroutine objects before calling asyncio.wait().

  (See comment in `` for an example "fix").

Note that, in general, it is not possible to know ahead of time whether all inputs to asyncio.wait() are coroutines or futures.  Furthermore, the fact that a given third-party library function is implemented as a regular function that returns a Future or a proper coroutine is an implementation decision which may not be part of the public interface.  Even if it is, the inputs to asyncio.wait() may come from complex code paths and it may be difficult to verify that all of them end up producing a Future.

As a consequence, the only reliable way to recover all results from asyncio.wait() is to explicitly call asyncio.ensure_future() on each of the inputs.

When doing so, both the membership test against the `done` set and the await expressions work as expected.

Quickly, there are several possible solutions:
- allow programs to await coroutine multiple times;
- make the set membership test of a coroutine object succeed; or
- change support for coroutine objects as inputs to asyncio.wait():
** update documentation for asyncio.wait() to explain this limitation; or
** explicitly reject coroutine objects; or
** warn when passing coroutine objects as inputs -- unless wrapped.

Related issue: proposes a patch to change the behaviour of awaiting a coroutine object multiple times in order to produce a RuntimeError on all awaits after the 1st.  While that change in behaviour would make it easier to diagnose the loss of the return value, it does not fix this issue.
Date User Action Args
2016-02-13 21:17:53André Caronsetrecipients: + André Caron, gvanrossum, vstinner, yselivanov
2016-02-13 21:17:53André Caronsetmessageid: <>
2016-02-13 21:17:53André Caronlinkissue26357 messages
2016-02-13 21:17:52André Caroncreate