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
calling .register on typing.KeysView subclass causes false positive error Member "register" is unknown #9296
Type checkers that include the recent changes from #8977#9058 (e.g. pyright v1.1.281) now incorrectly emit an error like Member "register" is unknown for the following line of code:
Type checkers that do not include those changes (e.g. pyright v1.1.278) do not emit any error for that line, as expected.
Copy/pasted excerpt:
importtypingastfrom ._typingimportKT# a typevarclassBidictKeysView(t.KeysView[KT], t.ValuesView[KT]):
"""Since the keys of a bidict are the values of its inverse (and vice versa), the :class:`~collections.abc.ValuesView` result of calling *bi.values()* is also a :class:`~collections.abc.KeysView` of *bi.inverse*. """dict_keys: t.Type[t.KeysView[t.Any]] =type({}.keys())
BidictKeysView.register(dict_keys) # <-- false positive error emitted here
Please let me know if there is any other info I can provide. Thank you!
It's relevant in that #9058 wouldn't have happened if not for #8977.
Also, #8977 was mostly done for aesthetic reasons, so if we need a short-term fix in typeshed, I suggest we roll back #8977 (as per option 2 in #8977 (comment))
Of course, in the medium term we should fix the mypy bug this exposed #9058 (comment) / python/mypy#13986 (maybe it's already fixed?). The reason CI didn't complain is because this needs python/mypy#13579 to break, which was not part of a released mypy at the time.
I'm assuming @jab ran into this in the context of bidict. We do have bidict in mypy_primer and didn't see any regressions, so maybe this is something mypy has some special casing for? There's a chance this might be the very first time we've had an issue where a pyright_primer would be useful
Also, #8977 was mostly done for aesthetic reasons, so if we need a short-term fix in typeshed, I suggest we roll back #8977 (as per option 2 in #8977 (comment))
Agreed that rolling back #8977 and #9058 seems like a good option for now.
I haven't looked but this feels like an area where typecheckers need to hardcode a lot of behavior, since Protocol classes and ABCs are special in ways that are core of the type system. It's not surprising that different type checkers handle this case differently.
Activity
JelleZijlstra commentedon Nov 29, 2022
I don't think the typeshed change you link to is relevant. Probably #9058 is the culprit instead.
hauntsaninja commentedon Nov 29, 2022
It's relevant in that #9058 wouldn't have happened if not for #8977.
Also, #8977 was mostly done for aesthetic reasons, so if we need a short-term fix in typeshed, I suggest we roll back #8977 (as per option 2 in #8977 (comment))
Of course, in the medium term we should fix the mypy bug this exposed #9058 (comment) / python/mypy#13986 (maybe it's already fixed?). The reason CI didn't complain is because this needs python/mypy#13579 to break, which was not part of a released mypy at the time.
I'm assuming @jab ran into this in the context of bidict. We do have bidict in mypy_primer and didn't see any regressions, so maybe this is something mypy has some special casing for? There's a chance this might be the very first time we've had an issue where a pyright_primer would be useful
AlexWaygood commentedon Nov 30, 2022
Agreed that rolling back #8977 and #9058 seems like a good option for now.
jab commentedon Dec 10, 2022
Thanks @JelleZijlstra, @hauntsaninja, and @AlexWaygood for looking at this.
I'm new to this codebase, but submitted #9348 with these reversions, along with a regression test. Hope this helps.
Yes.
TIL, cool and thank you!
Do you know, @JelleZijlstra?
FWIW, I believe this is not the very first (and maybe not even the second) time.
Looks like there's already a dedicated issue for considering a pyright_primer (#7642), maybe now the time is right?
Thanks again for working together on this.
JelleZijlstra commentedon Dec 10, 2022
I haven't looked but this feels like an area where typecheckers need to hardcode a lot of behavior, since Protocol classes and ABCs are special in ways that are core of the type system. It's not surprising that different type checkers handle this case differently.
Closing as #9348 was merged.