Author hniksic
Recipients JustinTArthur, Roman.Evstifeev, asvetlov, hniksic, mivade, yselivanov
Date 2020-10-02.08:14:04
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1601626444.8.0.534158867978.issue33533@roundup.psfhosted.org>
In-reply-to
Content
Hi, thanks for providing a PR. One thing I noticed is that the implementation in the PR yields results of the futures from the generator. This issue proposes a generator that instead yields the futures passed to as_completed. This is needed not just for consistency with concurrent.futures.as_completed, but also to allow associating results with the requests that produced them, which is an important use case for as_completed.

An example of how this is useful is the snippet at https://docs.python.org/3/library/concurrent.futures.html#threadpoolexecutor-example which you cannot implement with an as_completed that doesn't yield the original futures. The StackOverflow question at [1] inquires about that issue, and would be easily resolved by yielding the futures as concurrent.futures.as_completed does.

As far as I can tell, the needed change is simple: just yield `f` instead of `f.result()` from `_wait_for_one` when invoked from __anext__. (It must still return f.result() when called from __next__ for backward compatibility.)

[1] https://stackoverflow.com/questions/50028465/python-get-reference-to-original-task-after-ordering-tasks-by-completion
History
Date User Action Args
2020-10-02 08:14:04hniksicsetrecipients: + hniksic, asvetlov, Roman.Evstifeev, yselivanov, mivade, JustinTArthur
2020-10-02 08:14:04hniksicsetmessageid: <1601626444.8.0.534158867978.issue33533@roundup.psfhosted.org>
2020-10-02 08:14:04hniksiclinkissue33533 messages
2020-10-02 08:14:04hniksiccreate