homepage

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?