structurally equivalent namedtuples can confuse mypy in unions in some cases

[asottile-sentry]

Bug Report

some narrowing goes wrong and mypy ends up getting confused with a bunch of self-union types (A | A) and spurious errors

I'm not entirely sure the cause however

To Reproduce

from typing import NamedTuple


class AKey(NamedTuple):
    k: str

class A(NamedTuple):
    key: AKey
    s: str


class BKey(NamedTuple):
    k: str

class B(NamedTuple):
    key: BKey
    s: str


def f(x: A | B | str) -> A | B | str:
    if isinstance(x, str):
        return x
    else:
        return x._replace(s='wat')

Expected Behavior

no errors from the given snippet

Actual Behavior

$ mypy t3.py
t3.py:24: error: Invalid self argument "A | A" to attribute function "_replace" with type "Callable[[_NT, DefaultNamedArg(AKey, 'key'), DefaultNamedArg(str, 's')], _NT]"  [misc]
t3.py:24: error: Invalid self argument "B | B" to attribute function "_replace" with type "Callable[[_NT, DefaultNamedArg(BKey, 'key'), DefaultNamedArg(str, 's')], _NT]"  [misc]
t3.py:24: error: Incompatible return value type (got "A | B | A | B", expected "A | B | str")  [return-value]
Found 3 errors in 1 file (checked 1 source file)

Your Environment

• Mypy version used: 1.14.0
• Mypy command-line flags: n/a
• Mypy configuration options from mypy.ini (and other config files): n/a
• Python version used: 3.13.1

[asottile-sentry]

breaking the structural equivalence "fixes" the type errors -- but can break code

 class B(NamedTuple):
     key: BKey
     s: str
+    b_hax: bool = True

[asottile-sentry]

#15600 seems related -- but I don't understand type algebra enough to know if this is the same as what's explained here: #15600 (comment)

[asottile-sentry]

breaking the structural equivalence "fixes" the type errors -- but can break code

class B(NamedTuple):
key: BKey
s: str

• b_hax: bool = True

a more clever workaround which preserves the runtime behaviour is to duplicate the definition in/out of a TYPE_CHECKING block:

if TYPE_CHECKING:
    class B(NamedTuple):
        key: BKey
        s: str
        b_hax: bool = True
else:  # real implementation here
    class B(NamedTuple):
        key: BKey
        s: str

[sterliakov]

We create an "impossible" meet of tuples with different fallbacks here (TODO is apparently referring to this issue):

mypy/mypy/meet.py

Lines 987 to 992 in 4a76a1a

	if isinstance(self.s, TupleType):
	items = self.meet_tuples(self.s, t)
	if items is None:
	return self.default(self.s)
	# TODO: What if the fallbacks are different?
	return TupleType(items, tuple_fallback(t))

[sterliakov]

The monster produced from meeting A and B looks like

Union[
    tuple[tuple[builtins.str, fallback=__main__.AKey], builtins.str, fallback=__main__.A],
    tuple[tuple[builtins.str, fallback=__main__.AKey], builtins.str, fallback=__main__.B],
    tuple[tuple[builtins.str, fallback=__main__.BKey], builtins.str, fallback=__main__.A],
    tuple[tuple[builtins.str, fallback=__main__.BKey], builtins.str, fallback=__main__.B]
]

which looks suspicious: the cross-bred types cannot exist.