import p.b when p's __init__.py is not in build silently produces any

[msullivan]

The following test fails, producing no output:

[case testInitNotInBuild1]
# cmd: mypy -m p.a p.b
# flags: --follow-imports=skip
[file p/__init__.py]
[file p/a.py]
import p.b
p.b.f('hi')  # E: Argument 1 to "f" has incompatible type "str"; expected "int"
[file p/b.py]
def f(x: int) -> None: pass

Adding a reveal_type(p.b) reveals that its type is Any.

The following two variants of this test, using from ... import ..., both pass, however:

[case testInitNotInBuild2]
# cmd: mypy -m p.a p.b
# flags: --follow-imports=skip
[file p/__init__.py]
[file p/a.py]
from p.b import f
f('hi')  # E: Argument 1 to "f" has incompatible type "str"; expected "int"
[file p/b.py]
def f(x: int) -> None: pass

[case testInitNotInBuild3]
# cmd: mypy -m p.a p.b
# flags: --follow-imports=skip
[file p/__init__.py]
[file p/a.py]
from p import b
b.f('hi')  # E: Argument 1 to "f" has incompatible type "str"; expected "int"
[file p/b.py]
def f(x: int) -> None: pass

[gvanrossum]

In the first example, what's reveal_type(p)? I suspect it's also Any. Since `import p.b` in Python binds the local name `p` (to package `p`), I think this form requires p/__init__.py to be checked, but since it's not explicitly mentioned on the command line it isn't. Presumably in the other tests the requirement on `p` is less strict. (There's some kind of dummy parent package implied by the existence of p/__init__.py.) PS. Note that the -m flag in tests doesn't work the same way as the -m flag on the real mypy command line -- the latter requires exactly one module following. I think in tests it's pretty shallowly translated to p/a.py, p/b.py. PPSS. This is pure speculation, I haven't verified any of this by reading the sources.