You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Too strict behavior with --ignore-missing-imports #5226
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:
importwhatever.worksimportexisting.nonexistingx=whatever.works.f() # No errors, as expectedy=existing.nonexisting.g() # Module has no attribute "nonexisting"
At the same time both these work (in the same program, otherwise the second fails):
fromwhateverimportworks# no errorsfromexistingimportnonexisting# 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).
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>
.
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.
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.
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.)
Activity
gvanrossum commentedon Jun 17, 2018
ilevkivskyi commentedon Jun 17, 2018
Maybe. But what is the value of that error "Module has no attribute ..."?
ilevkivskyi commentedon Jun 17, 2018
Correction:
from existing import nonexistingalso fails. It however doesn't fail, if there is animport existing.nonexistingelsewhere.gvanrossum commentedon Jun 18, 2018
For me the deciding difference is whether it could reference something other than a module.
import existing.nonexistinghas to refer to a module, so--ignore-missing-importsapplies. Butfrom existing import nonexistingcould refer to a class, function or variable defined inexistingand as such it is not covered by--ignore-missing-imports. The presence ofimport existing.nonexistingelsewhere 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 commentedon Jun 18, 2018
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.bintofrom a import bturns it into an error.gvanrossum commentedon Jun 18, 2018
[-]Inconsistency in --ignore-missing-imports[/-][+]Too strict behavior with --ignore-missing-imports[/+]ilevkivskyi commentedon Jun 18, 2018
OK, I updated the title.
Make --ignore-missing-imports less strict (#5228)