Repository navigation
[Bug]: Mypy stubtest failure on disjoint_base #30551
Description
Bug summary
The recently released MyPy 18.1 supports PEP 800 – Disjoint bases in the type system. stubtest now flags the following errors in CI (e.g. in 0a744f0)
Actual outcome
matplotlib.dviread.Text is a disjoint base at runtime, but isn't marked with @disjoint_base in the stub <TypeInfo matplotlib.dviread.Text> Runtime: in file /home/runner/work/matplotlib/matplotlib/lib/matplotlib/dviread.py:69 def (x, y, font, glyph, width) Raw Output: error: matplotlib.dviread.Text is a disjoint base at runtime, but isn't marked with @disjoint_base in the stub Stub: in file /home/runner/work/matplotlib/matplotlib/lib/matplotlib/dviread.pyi:31 <TypeInfo matplotlib.dviread.Text> Runtime: in file /home/runner/work/matplotlib/matplotlib/lib/matplotlib/dviread.py:69 def (x, y, font, glyph, width)
matplotlib.container.Container is a disjoint base at runtime, but isn't marked with @disjoint_base in the stub <TypeInfo matplotlib.container.Container> Runtime: in file /home/runner/work/matplotlib/matplotlib/lib/matplotlib/container.py:5 def (*args, **kwargs) Raw Output: error: matplotlib.container.Container is a disjoint base at runtime, but isn't marked with @disjoint_base in the stub Stub: in file /home/runner/work/matplotlib/matplotlib/lib/matplotlib/container.pyi:10 <TypeInfo matplotlib.container.Container> Runtime: in file /home/runner/work/matplotlib/matplotlib/lib/matplotlib/container.py:5 def (*args, **kwargs)
Expected outcome
No error.
Activity
LangQi99 commented on Sep 12, 2025
https://github.com/matplotlib/matplotlib/pull/30543/commits/0a744f0ba180dca0a73bf351db89796a9854c7d6
This url can better show the outcome, while 0a744f0 may shows This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository. for some reason.
QuLogic commented on Sep 12, 2025
It looks like maybe we can pass --ignore-disjoint-bases for now? python/mypy#19740
Fix stubtest with mypy 18
tacaswell commented on Sep 16, 2025
Reading the PEP quickly, I suspect that this may be a bug in mypy as in both cases we are sub-classing tuple or NamedTuple which should be the disjoint base of those classes as:
and
In [16]: from collections import namedtuple In [17]: NT = namedtuple("NT", 'a, b') In [18]: class D(NT, tuple): ...: ... ...: In [19]: D(1, 2) Out[19]: D(a=1, b=2)which if NT and A were disjoint_bases from their parents should not be possible? The pep says "if there are multiple candidates then one which is a sub-class of all of the others is the disjoint_base", so it is consistent if our classes are disjoint_bases, but it is not clear to why they must be.
Further this works:
In [23]: class A(tuple): ...: ... ...: In [24]: class E(tuple): ...: ... ...: In [25]: class AE(A, E): ...: ... ...: In [26]: AE.mro() Out[26]: [__main__.AE, __main__.A, __main__.E, tuple, object] In [27]: AE((1, 2, 3)) Out[27]: (1, 2, 3)which if sub-classing tuple made you a disjoint baseclass would not work.
I tested this with py313.
timhoffm commented on Sep 16, 2025
I'm not following your examples. They seem more complicated than what we have. We have Container(tuple) and some children of Container that only inherit from it. There's no multiple inheritance involved.
tacaswell commented on Sep 16, 2025
Sorry, I was trying to make the point that these are not disjoint at runtime (as Python will let us do MI).
There was something in the PEP about pre/post 3.12 behavior of namedtuples that I did not fully understand.
timhoffm commented on Sep 16, 2025
Let's not bother for now. We have been getting along without disjoint base checks for 20+ years. If this is really a mypy issue then somebody else with find out. We can remove the option later once the feature has matured.