Bad circular imports are not rejected

[ashleyh]

If a.py contains

import b
name = 'a'
print(b.name)

and b.py contains

import a
name = 'b'
print(a.name)

then mypy compiles a.py without error, but the generated python throws an error because of the circular import.

(Found this one while refactoring mypy itself into packages)

[JukkaL]

When using the new Python-compatible syntax, the issue is that we do not detect invalid circular imports statically. This is a potential new feature -- updated labels accordingly.

[o11c]

Circular imports are valid somtimes, but mypy is buggy, I hit this in #721

[JukkaL]

Yeah, circular imports are pretty common in larger programs (even mypy has several). Some circular imports cause the program to always fail, and mypy could detect some of these. I'll edit the title to be less confusing.

[o11c]

@JukkaL in my driver PR I remove all the circular imports I think. They are only needed for typechecking (i.e. in string-quoted types), not actually running mypy.

The workaround I use is if False: import mypy.foo. Any fix that mypy forms should take this into account.

[JukkaL]

@o11c I saw that and it's a pretty neat trick. Alternatively, we could define a constant such as MYPY that is always False and do something like this:

from bar import MYPY
if MYPY: import foo

def f(x: 'foo.ClassName') -> None: ...

The if statement trick also supports from ... import, unlike a real circular import:

from bar import MYPY
if MYPY: from foo import ClassName

def f(x: 'ClassName') -> None: ...

It may be worth it to describe this in mypy documentation.

Also, mypy could complain if a type imported as above is used without literal escapes.

[dosisod]

Instead of a MYPY constant, we can use TYPE_CHECKING:

from typing import TYPE_CHECKING

if TYPE_CHECKING:
    from foo import ClassName

def f(x: 'ClassName') -> None: ...