The new implementation should also return futures, just like the one fromconcurrent.futures does. The difference is that with async iteration we can return theoriginal futures, which are guaranteed to have completed.

Changingyield future.result() toyield future in__aiter__ makes it correct, and compatible with PEP 3148.

The existing implementation ofas_completed already yields results. I also think yielding results rather than futures is more natural withasync for.

The existing implementation yields futures which you mustawait.

The idea is to yield futures which are guaranteed to have completed, as they complete. This is howconcurrent.futures.as_completed works, but the benefit goes beyond consistency withconcurrent.futures. It allows code to be robust in the face of exceptions raised by futures, and to associate side data with the futures and retrieve it fromas_completed. For example, when yielding futures,this usage example immediately becomes usable withasyncio.as_completed, just changingfor toasync for.

The sync version doesn't support that usage because it gives you adifferent future than any of those passed toas_completed. Among other things, that's what prompted the BPO issue.

As far as I can tell, your implementation can easily support that, just by removing.result() at theyield point.

You're right, I misread what was going on before. Thanks for the explanation!

Inheriting from object isn't necessary