Too strict behavior with --ignore-missing-imports

[ilevkivskyi]

I think the --ignore-missing-imports currently behaves a bit inconsistently. If I have an existing directory with only an empty __init__.py, then running mypy with --ignore-missing-imports gives this:

import whatever.works
import existing.nonexisting

x = whatever.works.f()  # No errors, as expected
y = existing.nonexisting.g()  # Module has no attribute "nonexisting"

At the same time both these work (in the same program, otherwise the second fails):

from whatever import works  # no errors
from existing import nonexisting # no errors

I think the first example should work as well, since all non-existing modules should be replaced with a dummy Any (and apparently it looks easy to fix, unless this is intentional behavior for some reasons).

EDIT: see #5226 (comment)

[gvanrossum]

I believe this has been discussed before but I don't recall the outcome. :-( Isn't this the reason we don't like partial packages in typeshed?

…

On Sat, Jun 16, 2018, 18:11 Ivan Levkivskyi ***@***.***> wrote: I think the --ignore-missing-imports currently behaves a bit inconsistently. If I have an existing directory with only an empty __init__.py, then running mypy with --ignore-missing-imports gives this: import whatever.worksimport existing.nonexisting x = whatever.works.f() # No errors, as expected y = existing.nonexisting.g() # Module has no attribute "nonexisting" At the same time both these work: from whatever import works # no errorsfrom existing import nonexisting # no errors I think the first example should work as well, since all non-existing modules should be replaced with a dummy Any (and apparently it looks easy to fix, unless this is intentional behavior for some reasons). — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#5226>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACwrMv0cInK58Vjt-_y95-T-of1A8wJqks5t9azPgaJpZM4UqqqS> .

[ilevkivskyi]

Isn't this the reason we don't like partial packages in typeshed?

Maybe. But what is the value of that error "Module has no attribute ..."?

[ilevkivskyi]

Correction: from existing import nonexisting also fails. It however doesn't fail, if there is an import existing.nonexisting elsewhere.

[gvanrossum]

For me the deciding difference is whether it could reference something other than a module. import existing.nonexisting has to refer to a module, so --ignore-missing-imports applies. But from existing import nonexisting could refer to a class, function or variable defined in existing and as such it is not covered by --ignore-missing-imports. The presence of import existing.nonexisting elsewhere implies that it refers to a submodule, so then the flag applies.

So I don't necessarily believe that "fixing" this will make things better -- it will just trade false positives for false negatives.

[ilevkivskyi]

So I don't necessarily believe that "fixing" this will make things better -- it will just trade false positives for false negatives.

So do you prefer false positives? I prefer false negatives. Also as Jukka mentioned in the PR some users may be surprised that refactoring import a.b into from a import b turns it into an error.

[gvanrossum]

In the end I agree that we need to solve this. I just wanted to explain that the original behavior was not that irrational but in fact was internally consistent. (The new solution will be too of course.)

[ilevkivskyi]

OK, I updated the title.