Improve gather typing when coros more than 5

[mnixry]

No description provided.

[github-actions]

Diff from mypy_primer, showing the effect of this PR on open source code:

core (https://github.com/home-assistant/core)
+ homeassistant/requirements.py:214: error: Subclass of "Integration", "BaseException", and "IntegrationNotFound" cannot exist: would have inconsistent method resolution order  [unreachable]
+ homeassistant/requirements.py:214: error: Right operand of "or" is never evaluated  [unreachable]
+ homeassistant/helpers/trigger.py:198: error: Statement is unreachable  [unreachable]
+ homeassistant/helpers/trigger.py:200: error: Statement is unreachable  [unreachable]
+ homeassistant/helpers/trigger.py:202: error: Statement is unreachable  [unreachable]
+ homeassistant/components/amcrest/camera.py:411: error: Incompatible types in assignment (expression has type "object", variable has type "bool")  [assignment]
+ homeassistant/components/amcrest/camera.py:411: error: Incompatible types in assignment (expression has type "object", variable has type "Optional[bool]")  [assignment]
+ homeassistant/components/amcrest/camera.py:411: error: Incompatible types in assignment (expression has type "object", variable has type "Optional[str]")  [assignment]

[JelleZijlstra]

This probably makes things worse in practice in cases where the gathered futures are heterogeneous. _T will be inferred to be either a join like object (mypy) or a big union (pyright), and you'll get false-positive errors because that type is not practical to work with.

[mnixry]

This probably makes things worse in practice in cases where the gathered futures are heterogeneous. _T will be inferred to be either a join like object (mypy) or a big union (pyright), and you'll get false-positive errors because that type is not practical to work with.

Thank you for your reply. I have experienced the type become an object when I'm using MyPy. Since I have used Pyright for work, I almost forgot about this. I just don't like to write “Anython” for the gathered result :)

Could you please give me some advice to improve this PR?

[JelleZijlstra]

I'm afraid there may not be a way to improve this type in the current type system. (Well, we could add overloads for more than 5 futures, but where to stop?)

PEP 646's variadic TypeVars seem like they would help, but it's not enough because we need to go from _FutureLike[T] to T for each element, and PEP 646 doesn't let you do that. There's been talk of a type-level Map operator, but there is no PEP for that yet. If that existed, we'd be able to write something like def gather(*futures: *Map[_FutureLike, Ts]) -> tuple[*Ts]: ....

Though we'd still have the problem that gather() returns a list, not a tuple. But there is no way to type a heterogeneous list, and there hasn't been a serious proposal to do that. So pragmatically, we may have to continue to lie and claim gather() returns a tuple.

Another alternative could be to write special-case logic in a type checker. Mypy may be receptive to that; pyright probably not.

[mnixry]

Thank you for your explanation. It seems there are no very great solution util the Map operator becomes available :(

I will close this PR soon.