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
Plugin interface for type narrowing on == comparisons #10708
I'm proposing a new plugin interface for type narrowing on == comparisons.
Pitch
Take the following code:
from enum import IntEnum
class MyIntEnum(IntEnum):
A = 1
B = 2
m: MyIntEnum
if m == 1:
pass
else:
reveal_type(m)
This should reveal MyIntEnum.B, but mypy can't know that because it has no idea about how the __eq__ method on MyIntEnum works.
A plugin interface together with a builtin plugin could fix that.
mypy would walk through the MyIntEnum MRO until it encounters a class that defines __eq__ and then look for a plugin able to handle this class.
The plugin matching the class will be called and can return two types. One narrowing for if the condition matches and one for if it doesn't.
This would also be useful for checking match statements (#10191). Currently I have to special case enums there, as match always compares emums with ==, while mypy only narrows types if enums are compared with is.
It would probably also make it possible to get rid of the special casing of a == type(A) and replace it with a plugin.
I would like to first hear some opinions about this before I start implementing it.
If this is mostly about enums, I think that it would be sufficient to special case comparison against enums. Enums are treated as a special thing in various places anyway. Similarly, if we need this for builtin types, we can possibly just hard code them. It's unclear if anybody cares about this feature enough outside stdlib that they'd write a plugin for this, making the extra plugin support of unclear value. I don't have a strong opinion on this, however.
Activity
JukkaL commentedon Jun 24, 2021
If this is mostly about enums, I think that it would be sufficient to special case comparison against enums. Enums are treated as a special thing in various places anyway. Similarly, if we need this for builtin types, we can possibly just hard code them. It's unclear if anybody cares about this feature enough outside stdlib that they'd write a plugin for this, making the extra plugin support of unclear value. I don't have a strong opinion on this, however.