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

Changing yield future.result() to yield future in __aiter__ makes it correct, and compatible with PEP 3148.

The existing implementation of as_completed already yields results. I also think yielding results rather than futures is more natural with async for.

The existing implementation yields futures which you must await.

The idea is to yield futures which are guaranteed to have completed, as they complete. This is how concurrent.futures.as_completed works, but the benefit goes beyond consistency with concurrent.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 from as_completed. For example, when yielding futures, this usage example immediately becomes usable with asyncio.as_completed, just changing for to async for.

The sync version doesn't support that usage because it gives you a different future than any of those passed to as_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 the yield point.

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

Inheriting from object isn't necessary