A type created with type(...) is not valid as a type

[mehaase]

Note: I tried searching for related issues but the search keyword type obviously has a lot of hits in this repo with a different meaning. Apologies if this has been asked before.

It seems that types created using type(...) are not valid as type annotations.

MyType = type("MyType", (dict,), {})
x: MyType = MyType()


class MyOtherType:
    pass
y: MyOtherType = MyOtherType()

The result is:

> mypy example/test.py
example/test.py:2: error: Variable "example.test.MyType" is not valid as a type
example/test.py:2: note: See https://mypy.readthedocs.io/en/latest/common_issues.html#variables-vs-type-aliases
Found 1 error in 1 file (checked 1 source file)

Is this considered a bug or an intentional design decision? Is there a way to use this kind of type as a type annotation?

Python 3.7.5, MyPy 0.770.

[JelleZijlstra]

This is generally too dynamic for mypy to understand. It would probably be quite difficult to make it work in mypy except in simple cases where all the arguments are static.

[g-braeunlich]

What about the following?

class X: pass

x: X # works

Y = cast(type, X)
y: Y # is not valid as a type

Z: type = X
z: Z # is not valid as a type

It would be cool to have at least one way to tell mypy that some object is actually a type, e.g. X: typing.Type[str] = type("X", (str,), {})

[gvanrossum]

But then using that object in an annotation is useless. You could just as well say ‘z: object’.

[g-braeunlich]

Also in my example X: typing.Type[str] = type("X", (str,), {}) ?
Would not x: X indicate x: str (or subtype of str)?

[gvanrossum]

Mypy doesn’t special-case calls to type() that way. To me this feels like something too dynamic to expect mypy to understand, sorry. And IIRC Type[str] has a different meaning (the type of ‘str’?).

[jenstroeger]

For visitors of this issue, there’s another related discussion here.