Problem subscripting asyncio.Future

[ronf]

I'm trying to create a type alias for an asyncio.Future, by doing something like:

_MyFuture = asyncio.Future[None]

Later on, I then do something like:

    loop = asyncio.get_event_loop()
    future: _MyFuture = loop.create_future()

    # spawn some other async task, passing future to it

    await future # Block until operation is complete

This works fine in Python 3.9 and 3.10, but I get an error in 3.8 and earlier of:

TypeError: 'type' object is not subscriptable

I can work around this by putting the definition inside an if TYPE_CHECKING: block, and later putting _Future in quotes wherever I use it, but that's pretty ugly and I've been trying to avoid such blocks. Can anyone think of a better way to deal with this? Is there anything which can be done in the stubs to fix this? I'm declaring other type aliases which use subscripts outside of a TYPE_CHECKING block in Python versions before 3.9 without seeing this problem. For instance, I do this with things like Optional and Sequence.

I can leave out the subscript when declaring the type alias and it does work in older versions of Python, but that implicitly makes the return type of the Future into Any, which reduces my mypy code coverage.

[gvanrossum]

As long as you're bound to support Python 3.8, you'll have to use the ugly if TYPE_CHECKING (perhaps combined with a check for sys.version_info < (3, 8)). It's the price you (and all of us) pay for wanting to use the latest features with older versions, alas.

…

On Mon, Aug 16, 2021 at 8:30 PM Ron Frederick ***@***.***> wrote: I'm trying to create a type alias for an asyncio.Future, by doing something like: _MyFuture = asyncio.Future[None] Later on, I then do something like: loop = asyncio.get_event_loop() future: _MyFuture = loop.create_future() # spawn some other async task, passing future to it await future # Block until operation is complete This works fine in Python 3.9 and 3.10, but I get an error in 3.8 and earlier of: TypeError: 'type' object is not subscriptable I can work around this by putting the definition inside an if TYPE_CHECKING: block, and later putting _Future in quotes wherever I use it, but that's pretty ugly and I've been trying to avoid such blocks. Can anyone think of a better way to deal with this? Is there anything which can be done in the stubs to fix this? I'm declaring other type aliases which use subscripts outside of a TYPE_CHECKING block in Python versions before 3.9 without seeing this problem. For instance, I do this with things like Optional and Sequence. I can leave out the subscript when declaring the type alias and it does work in older versions of Python, but that implicitly makes the return type of the Future into Any, which reduces my mypy code coverage. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#835>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAWCWMUHS2UKPXT4JEBBVSDT5HJWVANCNFSM5CI6VATA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> .

-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>

[hauntsaninja]

An else in your if TYPE_CHECKING block will make things nicer and obviate the need for quoting later:

if TYPE_CHECKING:
    _MyFuture = asyncio.Future[None]
else:
    _MyFuture = asyncio.Future

then just use _MyFuture in most places without quotes or worries.

There isn't really anything stubs can do about this... This is basically a problem with the runtime, which is why things are better in Python 3.9. (The only thing stubs could do is making Future not generic, but that would be the same as today's Future[Any])

Finally, if your minimum supported Python version is 3.7, in a lot of cases, from __future__ import annotations can ameliorate this class of problems. See https://mypy.readthedocs.io/en/latest/runtime_troubles.html#using-classes-that-are-generic-in-stubs-but-not-at-runtime for details.

[ronf]

Thanks for the quick responses!

I'll give the conditional a try. Since I refer to that type alias in other type aliases, this issue was causing a bunch of other types to indirectly get caught up in this, and at least that part of the problem should go away with this approach.

I did move my minimum Python version from 3.4 to 3.6 after 3.4 officially went EOL. However, I probably won't be doing a new major version of my package any time soon, so it may be a while before I can drop support for 3.6.

[ronf]

This appears to be working nicely, except for a minor nit that the "else" clause is getting flagged in mypy coverage due to its implicit use of Future[Any].