Fix crash on incompatible redefinition in named tuple

[ilevkivskyi]

Fixes #3759

Currently we don't support generic named tuples, so using a fallback to instance is a reasonable solution.
(Later, when we will support generic named tuples, maybe we could use item types to get a more precise type).

[gvanrossum]

This bug is a regression since 0.511, right? Is it worth cherrypicking the fix into the 0.521 release?

[ilevkivskyi]

This bug is a regression since 0.511, right?

I didn't do bisect, but I think this is very old, the code affected was last changed almost half year ago.

[gvanrossum]

Actually it seems to be caused by 3589c08, Add support for NamedTuple methods (#3081) by @JelleZijlstra.

[ilevkivskyi]

So actually few days after 0.511. Then formally speaking this is a regression.

[gvanrossum]

So how confident are you? Anyway I'm testing this against the Dropbox codebase.

[ilevkivskyi]

I think this should be quite safe (at least for sure not less safe than it was). There are only three possibilities: Instance, TupleType, and None. None can't happen, since this function is only called from within a class.

[gvanrossum]

Merged, as it did not introduce new errors in our codebase. I will also cp.

[JelleZijlstra]

Thanks for fixing the crash Ivan!

Arguably we should give an error for this case, since it breaks LSP. (If you take a tuple as an argument and use .count() on it, it will break if your tuple is actually a NamedTuple with a count attribute.) But that's less urgent.

[ilevkivskyi]

But that's less urgent.

The error is shown (see test). I just re-use the fallback Instance to resolve the attribute type.