Unsupported type Type[...] error when instantiating NamedTuple from class variable

[joshstaiger]

Run mypy 0.550 on the following code

from typing import NamedTuple, Type, cast

class A(NamedTuple): ...

A1: Type[A] = A  # no error
A2: Type[A] = A  # error: Unsupported type Type["A"]
A2()

def j(cls: Type[A]) -> None:  # error: Unsupported type Type["A"]
    cls()

class B(): ... # no error

B1: Type[B] = B
B1()

I see error: Unsupported type Type["A"] on the lines for A2 and def j, but not in other places, as indicated.

I'm probably hitting an edge case for NamedTuple here.

[gvanrossum]

The really odd thing is that removing the A2() call makes the error go away. I have a feeling that the error is really for that call but is given the line number for the definition of A2 instead of the call line.

[ilevkivskyi]

FWIW I have seen a very similar problem when working on self types in generic classes. Hopefully, my fix will also fix this one.

[mitar]

One more example:

import typing

T = typing.TypeVar('T')
L = typing.TypeVar('L', bound='List')

class List(typing.List[T]):
    def __init__(self, iterable: typing.Iterable = ()) -> None:
        super().__init__(iterable)

    def copy(self: L) -> L:
        return type(self)(self)

[mitar]

But this works:

import typing

L = typing.TypeVar('L', bound='List')

class List(typing.List):
    def __init__(self, iterable: typing.Iterable = ()) -> None:
        super().__init__(iterable)

    def copy(self: L) -> L:
        return type(self)(self)

So if I do not use T in class List(typing.List[T]):.

[ilevkivskyi]

It looks like instantiating (calling) Type[X] sometimes has problems if X is:

• a tuple type
• a generic type
• type variable with a bound to the above

Maybe there are some more details.

[mitar]

And Type[X] is called somewhere internally?

[mitar]

Is there any way to silence this error?

[ilevkivskyi]

Is there any way to silence this error?

Hm... this is the problematic part. It looks like it is impossible to silence the error if the Type[...] comes from type(self) or similar. I am therefore setting priority to high (anyway I wanted to work on this around New Year).

[mitar]

The issue is also that this is not available: #626

[elliott-beach]

There's a test (by @gvanrossum) describing that you can't take the type of a Tuple from when Type[C] was implemented:

mypy/test-data/unit/check-classes.test

Lines 2432 to 2437 in d8892c4

	[case testTypeUsingTypeCErrorUnsupportedType]
	from typing import Type, Tuple
	def foo(arg: Type[Tuple[int]]): # E: Unsupported type Type["Tuple[int]"]
	arg()
	[builtins fixtures/tuple.pyi]
	[out]

Since the above is basically taking Type[tuple], it seems like that is behavior is intended, or at least already known. testTypeUsingTypeCErrorUnsupportedType covers the same thing.

The behavior is basically caused by there being no case for TupleType in analyze_type_callee_callee, which builds the new type object:

mypy/mypy/checkexpr.py

Line 649 in d8892c4

def analyze_type_type_callee(self, item: Type, context: Context) -> Type:

.

The error with generics is related to the same function and also seems like a deliberate choice by @gvanrossum (https://github.com/python/mypy/blob/master/mypy/checkexpr.p#L672-L673).

[gvanrossum]

Note the difference between tuple and Tuple. PEP 484 forbids Type[Tuple[...]] but allows (implicitly) Type[tuple]. Since NamedTuple is closest to Tuple[...] (it has a fixed set of fields) it stands to reason that it's disallowed as well.

IMO the only real issue is that

A1: Type[A]

doesn't give an error unless you try to call A1(), and that it then puts the error on the definition of A1 rather than at the call site. Something's definitely fishy there.

[JukkaL]

Type[A] if A is a named tuple seems well-defined, unlike Type[Tuple[...]], since there is a specific type object A (and similarly for subclasses of A). There is no type object that is specific to Tuple[int, str], for example (it's just tuple which is shared between all tuple types).