Don't complain about code that catches ImportErrors

[JukkaL]

Conder this example from @benhoyt's scandir (https://github.com/benhoyt/scandir):

# Use the built-in version of scandir/walk if possible, otherwise
# use the scandir module version
try:
    from os import scandir, walk
except ImportError:
    from scandir import scandir, walk

Code like this is pretty common in Python modules that want to be backward compatible with older Python versions.

If mypy doesn't know about the scandir module (which is not in the std lib), mypy will complain about the code (note that os.scandir is Python 3.5 only, and isn't included in mypy stubs quite yet). However, I argue that the code is fine if the try block doesn't generate errors, since the except block will not be reached (unless some module is missing, but mypy assumes that all modules with a stub are available).

Here is a more formal rule:

Don't report errors for an except ImportError block if the corresponding try block only contains import statements and all the imported modules and names in the try block can be resolved.

Another related issue is code that imports a potentially non-existent module in a try block and falls back to a stdlib module in an except block. Not sure whether we should also ignore errors in the try block if the except block has no issues. Contrived example:

try:
    from scandir import scandir, walk
except ImportError:
    from os import scandir, walk

Should mypy report an error for the above code if no stub or implementation for scandir is available?

[gvanrossum]

There are tons of variations on this pattern though... Some code might import a 3rd party module in preference of a stdlib one... Maybe there are assignments following the import, or in the except block some variables are set to None, or a flag is set to False, ...

[NYKevin]

If you want to be really crazy, it would be nice to support something like this:

In __init__.py (of whatever package):

import sys
try:
    from . import _cFoo as foo
except ImportError:
    from . import _foo as foo
sys.modules[__name__ + '.foo'] = foo

But maybe that's asking a bit much. For my use case, I wrote out a separate foo.pyi file even though there is no foo.py file. That's legal, right?

[o11c]

You can also use type: ignore

[JukkaL]

Yeah, you can always add a stub file even if there is no corresnponding .py file. If a stub exists, mypy trusts it.

[JukkaL]

Adding 'priority' as this seems to be a very common problem when migrating existing code. We still don't have a clear understanding of how exactly we should fix this, however.

[ddfisher]

#1107 will happen first; is more important for now.

[OJFord]

A similar pattern:

try:
    from foo import bar
except ImportError:
    pass
else:
    # do something with bar

Here mypy will treat bar: Any rather than whatever it actually is, even if we have stubs for it.

[JukkaL]

This seems too difficult to support in a general enough fashion. Using # type: ignore seems like a reasonable compromise and it already works.