False positive errors with anonymous and inline declaration of namedtuple types

[jessekv]

Bug Report

Mypy raises false positive errors with anonymous and inline declaration of namedtuple types.

To Reproduce

from collections import namedtuple

dim = namedtuple("Dimension", ["x", "y"])(2, 3)

This should be equivalent to the following, which mypy gets correct:

from collections import namedtuple

Dimension = namedtuple("Dimension", ["x", "y"])
dim = Dimension(2, 3)

(Example taken from here: https://stackoverflow.com/a/26405216)

Expected Behavior

No error raised.

Actual Behavior

$ mypy namedtuple.py 
namedtuple.py:3: error: Too many arguments for "tuple"  [call-arg]
namedtuple.py:3: error: Argument 1 to "tuple" has incompatible type "int"; expected "Iterable[Any]"  [arg-type]
Found 2 errors in 1 file (checked 1 source file)

My Environment

$ mypy --version
mypy 1.7.1 (compiled: yes)
$ python --version
Python 3.11.6

[JelleZijlstra]

I'm not sure this should be supported; it's outside the standard type system.

[erictraut]

@JelleZijlstra, what do you mean "outside the standard type system"? This is documented behavior, and there is no theoretical reason why a type checker cannot support it. FWIW, pyright supports it.

If you don't want to support it for in mypy because it's infrequently-used and there are other higher-priority issues in the mypy issue tracker, that's understandable, but I don't think "it's outside the standard type system" is a good justification.

[JelleZijlstra]

The relevant spec section for TypedDict (https://typing.readthedocs.io/en/latest/spec/typeddict.html#alternative-syntax) only uses the X = TypedDict("X", ...) assignment syntax, though it doesn't explicitly say that is the only place where the syntax is allowed. (The spec says nothing at all about namedtuple.)

I was going off the analogy with similar type system features like TypeVar, where it was my understanding that the type system required that you use the Name = Call("Name") syntax.

Surprisingly (to me), though, pyright even allows x = NewType("Y", int)(3) and class X(Generic[TypeVar("T")]): pass (https://pyright-play.net/?code=GYJw9gtgBALgngBwJYDsDmUkQWEMoDiApikSEgMYA0UAckQO4AqiRNLCRAagIYgBQ-AB5QAvHUYciACgBEATVk1UMAJTSAzKsEUANjwDOBqAA1pxUuQoBtKbxByms1QF1VALn5RvUBIYNAA). That does strengthen the case for allowing this in mypy also.

[erictraut]

Yeah, pyright enforces name consistency if you assign one of these constructs to an identifier. If you don't assign it to an identifier (e.g. you use it inline), then there's no name consistency to enforce. At least, that's the way I've been thinking about it.

If we think this is an area where it's desirable to have increased consistency between type checkers, we may want to clarify the desired behavior in the typing spec.