Recent change to concurrent/futures/_base.pyi broke a bunch of code #6033
Description
I just pulled the latest typeshed stubs for inclusion in the next release of pylance, and I noticed that a recent change to concurrent/futures/_base.pyi triggered a bunch of our internal smoke tests.
The problem is that it now imports the type Set from collections.abc rather than from typing. But collections.abc.Set is aliased to typing.AbstractSet which is not type compatible with typing.Set. Was this change intended? What is the implication of reverting it?
I've temporarily backed out this change from the copy of typeshed that we ship with pylance because I think it's going to be pretty disruptive.
Activity
JelleZijlstra commented on Sep 14, 2021
cc @HunterAP23 who wrote the PR.
It doesn't look like this change was intentional; probably it just came with switching Iterable and Mapping to being imported from collections.abc. I'd be OK with reverting this part of the PR, or just using set[] directly.
At some point it may be helpful to set up a pyright-primer complementing mypy-primer to find issues with pyright in our CI.
erictraut commented on Sep 14, 2021
Thanks @JelleZijlstra.
This issue wasn't specific to pyright. Mypy would have reported the same issue if it were run on this code. We use some internal Microsoft Python code bases as a smoke test for pyright, and that's where I discovered the problem. It also triggered an error in one of pyright's unit tests, which happened to use the affected module.
Fix set annotations in concurrent.futures._base
srittau commented on Sep 14, 2021
This was just an oversight. #6034.
HunterAP23 commented on Sep 14, 2021
It was an oversight on my part - thank you to both srittau and akuli for correcting it.