Do not use Any in NamedTuple() constructor - #6489

This doesn't seem correct to me. The following fails at runtime:

NamedTuple("Foo", [("abc", 123)])
NamedTuple("Foo", None, abc=123)

@srittau NamedTuple is special enough, it is probably special-cased in type-checkers.

For example, mypy handles this correctly:

from typing import NamedTuple

Foo = NamedTuple("Foo", [("abc", 123)])
Bar = NamedTuple("Bar", None, abc=123)

Output:

out/ex.py:3: error: Invalid type: try using Literal[123] instead?
out/ex.py:4: error: Invalid type: try using Literal[123] instead?

But, I would like to drop an extra comment on object vs type type in fields / **kwargs here. It would be ideal to make them to work with type. But, right now _SpecialForm items like Literal[123] do not fit type annotation: out/ex.py:3: error: List item 0 has incompatible type "Tuple[str, object]"; expected "Tuple[str, type]". So, object is the least troublesome type for now 😞

NamedTuple is special enough, it is probably special-cased in type-checkers.

Maybe if you added a comment clarifying that the stub is "deliberately incorrect" here? 🙂 Something like:

# NOTE: The overloads for __init__ are not strictly accurate
# (type for `fields` and `**kwargs` should be more precise than `object`)
# but typing `NamedTuple` like this makes it easier for mypy to special-case

I think we should just keep Any, our marker for situations like this.

I think we should just keep Any, our marker for situations like this.

As I said in #6489 (comment), Any causes some problems in mypy when --disallow-any-expr is activated. The fix for it would not be as easy on mypy's side. But, probably doable in case this PR won't be accepted.

I will attach @AlexWaygood's comment. Maybe this would be good enough 🙂

I'm hesitant to make "wrong" changes to typeshed to benefit a single type checker. Sometimes this is unavoidable, but I'd like to see other avenues explored first. I'd be interested what other maintainers think, though. Cc @JelleZijlstra @hauntsaninja @Akuli

To me, it seems unlikely that anyone actually wants to use mypy with --disallow-any-expr and also create namedtuples using the Foo = NamedTuple(...) syntax, and not the class Foo(NamedTuple) syntax. If the maintainers of a project have the time to get rid of all Any types, why wouldn't they also switch to the class-based NamedTuple syntax, which in my opinion just looks more readable?

According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉

Agree with @srittau.