Typing: Generic typing with asyncio.Future?

[LiraNuna]

First, I apologize if this is reported in the wrong place.

What's the right way to generically use the asyncio.Future type? When dealing with futures, it's often needed to use (for example) Future[int] to represent that this future will generate an int (or exception)

[gvanrossum]

You might ask this kind of question in the typeshed repo or on Gitter. But I think I see your point: when you write

async def foo(f: Future[int]) -> None:
    a = await f

you get a runtime error on the Future[int] annotation because the runtime type is not generic.

Until we make things in the stdlib generic (which isn't likely to happen soon as there are concerns about the slowdown this will cause) you can use a forward reference as a workaround:

async def foo(f: 'Future[int]') -> None:
    a = await f

[LiraNuna]

@gvanrossum now that 3.7 solved this issue with PEP 560, are there plans to fix this?

[gvanrossum]

Not yet. In 3.7, asyncio.Future is not generic. There is still considerable resistance to making classes in the stdlib generic. The right place to bring this up is now the python-ideas mailing list at python.org.

[wookayin]

@LiraNuna Why is this issue closed? I think Future is still not generic.

[LiraNuna]

I think I closed this because @gvanrossum has mentioned that this requires stdlib to be generic, which I take as a separate task which probably should not belong to this repo, but to CPython itself. There is also a workaround to use string annotation.

However, it's been over a year since I closed this task and I may have forgot other reasons.

I could reopen this issue if people wish, however I think a better effort should be spent toward a PEP to generic-ify the standard lib.

[gvanrossum]

In Python 3.9, Future will be generic.

[LiraNuna]

For those interested, it seems to be covered as a part of https://www.python.org/dev/peps/pep-0585/