Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

False positive errors with anonymous and inline declaration of namedtuple types #16660

Open
vdwees opened this issue Dec 13, 2023 · 4 comments · May be fixed by #16673
Open

False positive errors with anonymous and inline declaration of namedtuple types #16660

vdwees opened this issue Dec 13, 2023 · 4 comments · May be fixed by #16673
Labels
bug mypy got something wrong topic-named-tuple

Comments

@vdwees
Copy link

vdwees commented Dec 13, 2023

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
@vdwees vdwees added the bug mypy got something wrong label Dec 13, 2023
@JelleZijlstra
Copy link
Member

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

@erictraut
Copy link

@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
Copy link
Member

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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug mypy got something wrong topic-named-tuple
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants