"Module has no attribute" error when using "__import__()"

[blueyed]

I've noticed that __import__('pdb').set_trace() is handled differently than import pdb; pdb.set_trace():

% mypy =(echo "__import__('pdb').set_trace()"; echo "import pdb; pdb.set_trace(); pdb.meh")
/tmp/zshkq7d0B:1: error: Module has no attribute "set_trace"
/tmp/zshkq7d0B:2: error: Module has no attribute "meh"
Found 2 errors in 1 file (checked 1 source file)

I think this should behave the same.
I've not checked other modules, but pdb.set_trace is in typeshed.

mypy master (28423cd)

[msullivan]

This is expected: mypy doesn't know what module is being imported when __import__ is used.

You could potentially make an argument that the stub for __import__ in typeshed should return Any, though.

[tucked]

FWIW, setuptools namespace packages get hit by this if you use the code suggested in https://packaging.python.org/guides/packaging-namespace-packages/#pkg-resources-style-namespace-packages:

__import__('pkg_resources').declare_namespace(__name__)

[blueyed]

@msullivan

This is expected: mypy doesn't know what module is being imported when __import__ is used.

I wonder if it could not just assume "import X" being used for __import__("X")?
(obviously more tricky with dynamic imports like __import__(modname), but that's not the case here)

[gvanrossum]

I wonder if it could not just assume "import X" being used for import("X")?

I wouldn't be so quick. If someone writes xyzzy = __import__("xyzzy") instead of import xyzzy maybe they have something they want to hide from the type checker?

The code given in the packaging docs seems to be trying to avoid creating a local variable xyzzy -- there are other ways to do that though, and I would personally never have written those recommendations in that style. I guess someone was proud of a clever hack they came up with, but the may effect is that readers are more likely to copy-and-paste magical stuff they don't understand.

I'd be sympathetic if you were to make __import__ return Any in typeshed though.

[blueyed]

maybe they have something they want to hide from the type checker?

Wouldn't / shouldn't # type: ignore be used then?

I guess someone was proud of a clever hack they came up with

__import__('pdb').set_trace() is similar: just works around linters complaining about multiple statements on one line (as would be the case with import pdb; pdb.set_trace(), and uses only a single line in the first place).
It's not something important for me (only temporary code in this case), of course.

[blueyed]

Can you hint mypy that a var is of a specific ModuleType currently in any way?
Isn't that a valid feature request, so that this would work:

os2 = __import__("os")  # type: …
reveal_type(os2.EX_USAGE)

Would something new like typing.ModuleType would work, which takes a name as an argument, and would result in what "import os" uses?
Where/how does mypy handle the "import" statement?

[JukkaL]

@blueyed That isn't supported at the moment. If you want to propose this feature, you can create an issue at https://github.com/python/typing or start a discussion at the typing-sig list, since this requires some new type annotation syntax.