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-15.18:03:37
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Hi Guido,

Thanks for the quick reply :-)

AFAICT, there seem to be three possible directions regarding this issue -- for both wait() and as_completed():

1) remove the need for ensure_future(): make the membership test succeed and allow multiple await expressions on the same coroutine;

2) fail fast: reject coroutine objects as inputs to wait() and reject multiple await expressions on coroutine objects (see issue #25887);

3) clarify API usage: deprecate couroutine objects and enhance docs for wait(), as_completed() and ensure_future().

From a pure API standpoint, #1 makes the API more uniform and less surprising, #2 makes it easier to detect and fix incorrect usage and #3 accelerates troubleshooting when people get bitten by this quirk in the API.

You're right that technically, the case of side-effect-only coroutine invocations is a use case that's currently supported by wait() and that removing this (e.g. by adopting #2) would be a compatibility break.  I personally doubt that this is a common use case as both wait() and as_completed() seem specifically designed to recover the results, but I'm not an asyncio expert either.

Asyncio is still young and is undergoing adoption, so I would like to see this issue resolved without resorting to #3.

Any chance #1 or #2 can be considered?
Date User Action Args
2016-02-15 18:03:37André Caronsetrecipients: + André Caron, gvanrossum, vstinner, yselivanov
2016-02-15 18:03:37André Caronsetmessageid: <>
2016-02-15 18:03:37André Caronlinkissue26357 messages
2016-02-15 18:03:37André Caroncreate