Thanks for the manual backporting!
Python 3.6 and 3.7 are in secure mode, they don't accept such changes

No worries, understood!

Hello. I found that the documentation is still slightly misleading, that or the implementation is: if given generator-based iterables to asyncio.as_completed a TypeError is raised. I prepared this simple test:

import asyncio


async def sleep_job(n):
    await asyncio.sleep(n)
    return n


async def test():
    print("with lists")
    for job in asyncio.as_completed([sleep_job(n) for n in (4, 2, 3)]):
        print(await job)

    print("with sets")
    for job in asyncio.as_completed({sleep_job(n) for n in (4, 2, 3)}):
        print(await job)

    print("with generators")
    # This raises: TypeError: expect an iterable of futures, not generator
    for job in asyncio.as_completed(sleep_job(n) for n in (4, 2, 3)):
        print(await job)


if __name__ == "__main__":
    asyncio.run(test())

Maybe this is the intended behaviour, in which case the documentation could use some sort of warning. But I'm not sure the restriction on generators is intended.

¿What do you think? ¿Should I report this as a documentation bug?

My asyncio background is severely lacking, the relevant part of the code seems to be producing a false positive here:

    if futures.isfuture(fs) or coroutines.iscoroutine(fs):
        raise TypeError(f"expect an iterable of futures, not {type(fs).__name__}")

On the other hand I vaguely recall there may be a historical reason for this, someone more familiar with asyncio would have to provide some context.