AssertionError: Cannot find X for Y.X (incremental with warm cache)

[gvanrossum]

This is similar to #2451 but the cause is different. I haven't boiled it down yet but the clue seems to be there's a NamedTuple definition inside a [EDITs from here:] for-loop inside a method. And another report where there's a namedtuple inside a method.

[gvanrossum]

OK, simple repro: run mypy -i main.py ntcrash.py twice (without touching any files in between) where:

• ntcrash.py:

from typing import NamedTuple

class C:
    def f(self) -> None:
        A = NamedTuple('A', [('x', int), ('y', int)])

• main.py:

import ntcrash

[gvanrossum]

The problem is in the code that @kirbyfan64 fixed -- it's still broken in this case due to the peculiarities of how namedtuple classes are bootstrapped in the mypy code.

[elazarg]

Is this the 5th item in #2090 - "handle locally-defined namedtuple"?

[gvanrossum]

Yes, that's right. I'm not sure how to resolve it. Maybe the "qualified name" should be similar to what we use at runtime? E.g. with this code

class C:
    def f(self):
        class D: pass
        return D()
d = C().f()
print(d.__class__.__qualname__)

the output is C.f.<locals>.D. Combined with the module name that might work? But we'd have to introduce a namespace for the method.

Thinking aloud, another possibility would be to give the inner class a synthetic qualified name starting with a digit, e.g. C.0001_f_D (plus module prefix).

[gvanrossum]

(The key requirement here being simply that whatever the qualified name is can be found by the lookup method in fixup.py. We may have to modify both the qualified name and the lookup function to deal with the special case.)

[gvanrossum]

I'm going crazy. I can only make my repro "work" (i.e. cause the AssertionError) if I make main.py import a non-existent symbol from ntcrash, e.g.from ntcrash import nope.

[elazarg]

It's unrelated to the content. You should touch main.py before running mypy.

[gvanrossum]

That doesn't work for me. I delete the cache before starting. I really do have import something non-existing from ntcrash into main.

[gvanrossum]

Here's a test with the repro: ead98b3

[gvanrossum]

Note there are other variants, e.g.

class C:
    def a(self) -> None:
        class D:
            def f(self) -> None:
                A = NamedTuple('A', [('x', int), ('y', int)])

[elazarg]

For me it works only if I touch main.py after ntcrash.py

[gvanrossum]

This is a tremendously fertile bug breeding area. :-( See the gyrations in the PR where I'm attempting to fix this, #2553. See also #2559, inspired by some test cases there.

[ilevkivskyi]

The problem is still there if the code in ntcrash.py in the original example is more deeply nested:

from typing import NamedTuple

class C:
    def f(self) -> None:
        class D:
            class E:
                def g(self) -> None:
                    A = NamedTuple('A', [('x', int), ('y', int)])
                    self.a = A(1, 1)
        self.c = D.E().a

This could be easily fixed by always storing "anonymous" named tuples in globals.
I understand this situation is super rare, just wanted to mention this here, maybe at some someone will decide to fix this very minor thing.

[JukkaL]

@ilevkivskyi Can you create a new issue for the remaining problem, since otherwise it's easy to miss? We can tag it as low priority, but I'd like to keep track of crash bugs.

[ilevkivskyi]

@JukkaL OK, here it is #2931

[JukkaL]

@ilevkivskyi Thanks!