Repository navigation
Cannot determine consistent method resolution order (MRO) when inheriting from both MutableSequence and list #11427
Description
Bug Report
There are some scenarios where inheriting from MutableSequence and built-in list (in this exact order) is important. This is the case for atoml and tomlkit.
However this results in a typecheck error with mypy: Cannot determine consistent method resolution order (MRO)
Please notice no runtime error is found.
To Reproduce
Consider the following simplified example (extracted from atoml/tomlkit):
example.py
from typing import Optional
from collections.abc import MutableSequence
class Item:
def __init__(self, comment: Optional[str] = None):
self._comment = comment
class Array(Item, MutableSequence, list):
def __init__(self, values: list, comment: Optional[str] = None):
Item.__init__(self, comment)
list.__init__(self, values)
if __name__ == '__main__':
a = Array([0, 1, 2])
print([p.__name__ for p in a.__class__.__mro__])Expected Behavior
I would expect the MRO detected by mypy is exactly the same one given in runtime, i.e.:
['Array', 'Item', 'MutableSequence', 'Sequence', 'Reversible', 'Collection', 'Sized', 'Iterable', 'Container', 'list', 'object']Actual Behavior
During runtime the MRO is well defined and works as expected:
$ python3 example.py
['Array', 'Item', 'MutableSequence', 'Sequence', 'Reversible', 'Collection', 'Sized', 'Iterable', 'Container', 'list', 'object']But mypy fails to detect it and get completely lost when checking the Array class.
$ mypy example.py
example.py: note: In class "Array":
example.py:10: error: Cannot determine consistent method resolution order (MRO) for "Array" [misc]
class Array(Item, MutableSequence, list):
^
example.py: note: In member "__init__" of class "Array":
example.py:12: error: Argument 1 to "__init__" of "Item" has incompatible type "Array"; expected "Item"
[arg-type]
Item.__init__(self, comment)
^
example.py:13: error: No overload variant of "__init__" of "list" matches argument types "Array",
"List[Any]" [call-overload]
list.__init__(self, values)
^
example.py:13: note: Possible overload variant:
example.py:13: note: def [_T] __init__(self, self: List[_T], iterable: Iterable[_T]) -> None
example.py:13: note: <1 more non-matching overload not shown>
Found 3 errors in 1 file (checked 1 source file)Your Environment
- Mypy version used: 0.910
- Mypy command-line flags:
None - Mypy configuration options from
mypy.ini(and other config files):
mypy.ini
[mypy]
pretty = True
show_error_codes = True
show_error_context = True
show_traceback = True
ignore_missing_imports = True
warn_redundant_casts = True
warn_unused_ignores = True- Python version used: 3.8.0
- Operating system and version: Ubuntu 18.04.5 LTS
Please notice that while this particular choice of inheritance is debatable, it is fundamental for the way atoml/tomlkit work. We need MutableSequence as a mixin to implement the custom logic, but we also want the objects to be considered lists, so the users can use the API transparently as if they were dealing with built-in objects (this is an important aspect of the design).
Activity
erictraut commentedon Nov 1, 2021
I think mypy is doing the correct thing here based on the type information provided in typeshed. Pyright also emits the same error in this case.
The problem appears to be due to a "lie" in the definition of the
listclass inbuiltins.pyi. It indicates thatlistderives fromMutableSequence, but at runtime it does not. I don't see a way to fix this without breaking a lot of existing assumptions.You may need to simply ignore the error in this case by using a
# type: ignorecomment.abravalheri commentedon Nov 1, 2021
I am afraid
# type: ignoreis not a good solution here (it was the first thing I tried to be sincere 😅).What happens is that once mypy have problems to detect the MRO any subsequent usage of objects from the
Arrayclass is compromised in terms of typechecking. In practicemypyforgets the class inherits from any of its parents.Going for a
# type: ignoreapproach, means adding it to all the calls to inherited methods and in practice doing no type check in any of them.Just as an example, by doing:
The errors would still be:
erictraut commentedon Nov 1, 2021
Ah yeah, that's a problem. Maybe the best fix is for mypy to build an MRO even if it's not consistent rather than forgetting the entire class hierarchy. This is what pyright does in this circumstance, and it appears to work fine, at least in this case. Other than the initial error (reporting the MRO consistency issue), subsequent uses of the class work fine.
Use typecheck workaround for custom list/dicts
Use typecheck workaround for custom list/dicts
hauntsaninja commentedon Jun 20, 2025
#17713 should resolve this