You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Recent change to concurrent/futures/_base.pyi broke a bunch of code #6033
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.
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.
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.
Activity
JelleZijlstra commentedon 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 usingset[]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 commentedon 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 commentedon Sep 14, 2021
This was just an oversight. #6034.
HunterAP23 commentedon Sep 14, 2021
It was an oversight on my part - thank you to both srittau and akuli for correcting it.