André Caron added the comment: 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? ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26357> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
