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: ...

[mahmoudajawad]

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

@JukkaL, I knew about using False-y condition from some of the packages that already implemented this, but to my surprise I still needed the quotes, which I thought would be somehow magically get resolved automatically at runtime (okay, sometimes I pause the engineering mentality), but it isn't. To confirm whether this is a known issue, I searched and came across this. Is this yet to be implemented or it is implemented but for some reason I'm not getting the warning?

[JelleZijlstra]

@mahmoudajawad in recent versions of Python 3, you can use from __future__ import annotations and you won't need to use string annotations (except for a few unusual contexts).

[hauntsaninja]

#9763 will help document from __future__ import annotations and other tricks for dealing with import cycles.

[mahmoudajawad]

@JelleZijlstra, I see. I was under impression this has different purpose. I just tried it and it worked. Thanks for the suggestion.