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
Metaclass is not properly inherited when using multiple inheritance with int #2824
Running this with Python 3 shows that D's metaclass is M, but when checking this with mypy, we get the error
u.py:10: error: "D" has no attribute "foo"
on the last line, showing that mypy doesn't believe so.
This seems unique to int (or perhaps builtin types?) -- when create a separate class A (without a metaclass) and use that instead of int, there is no error.
FWIW this prevents me from fixing #2305 (iterating on enums) -- I can get it to work for Enum but not for IntEnum, because it multiply inherits from int and from Enum.
In general, the class/metaclass hierarchy in typeshed does not mirror the hierarchy in Python. I'm not sure, but it could be the reason. Perhaps the special casing of ABCMeta in mypy is also a problem.
Removing SupportsInt and SupportsFloat from baseclasses makes the error go away. SupportsAbs[int] has nothing to do with the error. Since the formers have ABCMeta as a metaclass, and the latter does not, It points to ABCMeta as the problem.
Well I guess I'm completely wrong. Perhaps it's a simple case of choosing the most derived common metaclass. In typeshed type(int) == ABCMeta. In Python type(int) == type.
There are additional checks to add to the subtype visitor that makes this problem go away, but something bothers me. The variable seems to be overly constrained by a class not defined yet. We should add another check for the metaclass declaration, to verify that we are constrained correctly by the type of cls.
As I have mentioned in a different discussion here, it might make sense to use the form cls: Meta[T] which means precisely the type whose metaclass is a subclass of Meta (directly inheriting the generic [] operator from Type). Then we don't need to constrain further T in any way.
Activity
elazarg commentedon Feb 7, 2017
It does not reproduce in unit tests.
elazarg commentedon Feb 7, 2017
In general, the class/metaclass hierarchy in typeshed does not mirror the hierarchy in Python. I'm not sure, but it could be the reason. Perhaps the special casing of ABCMeta in mypy is also a problem.
elazarg commentedon Feb 7, 2017
Removing SupportsInt and SupportsFloat from baseclasses makes the error go away. SupportsAbs[int] has nothing to do with the error. Since the formers have ABCMeta as a metaclass, and the latter does not, It points to ABCMeta as the problem.
elazarg commentedon Feb 7, 2017
Well I guess I'm completely wrong. Perhaps it's a simple case of choosing the most derived common metaclass. In typeshed
type(int) == ABCMeta. In Pythontype(int) == type.elazarg commentedon Feb 7, 2017
A possible solution: make EnumMeta inherit ABCMeta, so it will be the most derived common metaclass.
gvanrossum commentedon Feb 8, 2017
That mostly works, but I needed to add a
# type: ignore. Thoughts? https://github.com/python/typeshed/tree/enum-iterelazarg commentedon Feb 9, 2017
Is there some problem with selftype? I have encountered something, but I wasn't sure.
gvanrossum commentedon Feb 9, 2017
Without that I get
FWIW the test program is
and its output (less the error) is
which is exactly what it should be.
elazarg commentedon Feb 9, 2017
There are additional checks to add to the subtype visitor that makes this problem go away, but something bothers me. The variable seems to be overly constrained by a class not defined yet. We should add another check for the metaclass declaration, to verify that we are constrained correctly by the type of cls.
elazarg commentedon Feb 9, 2017
As I have mentioned in a different discussion here, it might make sense to use the form
cls: Meta[T]which means precisely the type whose metaclass is a subclass of Meta (directly inheriting the generic [] operator from Type). Then we don't need to constrain further T in any way.elazarg commentedon Sep 8, 2017
Root cause: python/typeshed#1595
JelleZijlstra commentedon Sep 11, 2017
Recap: