Repository navigation
module references aren't followed correctly #1741
Description
It seems that given an imported module and a reference to that module, mypy doesn't follow the reference.
Example:
# main.py
from test import mod
mod.blah()
for m in [mod]:
m.blah()
# test/mod.py
def blah() -> None:
print("blah")MYPYPATH=. bin/mypy main.py will result in
main.py:5: error: "module" has no attribute "blah"
Note that mypy does not complain about mod.blah(), which is resolved correctly.
I apologize if this is a known bug, I read a lot of issues before writing this up, but wasn't able to find anything relating to this.
Activity
gvanrossum commentedon Jun 23, 2016
IIUC the 'mod' object in main's global namespace is special, it knows exactly which module it references. But when you put a module in a list like your example (or do anything else with it other than plain assignment or an attribute reference), the resulting type becomes just the generic
moduleand has no attributes except__name__and such.What was your real-world use case?
jdelic commentedon Jun 23, 2016
I have a command-line application that, when started, calls
init_subsystem()on multiple modules, each of which then does things like validate command-line parameters and loading plugins usingpkg_resources. So my real code looks like this:I could just unroll the loop as a work-around... but is there a better solution?
...will probably work, but strikes me as unwieldy.
gvanrossum commentedon Jun 23, 2016
I see. Your special case defines an "interface" for each module to follow. Honestly I think the for-loop is a little clever here, so I would just unroll the loop. Or just add a
# type: ignoreto the call.I know what mypy could do, in theory, but I don't think it's worth the effort of actually implementing it.
fabianhjr commentedon Jul 20, 2016
Just found a case form an existing codebase,
The module
threadinghas a function/attributeenumeratewhich is is used to check if there are other threads alive before exiting/restarting.https://github.com/fabianhjr/home-assistant/blob/improvement-typing/homeassistant/__main__.py#L276,L281
gvanrossum commentedon Jul 20, 2016
@fabianhjr What error do you get? I don't see how that code snippet relates to this issue yet -- the issue is about the type of
[mod]being represented poorly (losing the fact that its values are all themodmodule). I assume your problem is merely that the Python 3 stub for threading in typeshed doesn't have a definition for enumerate(). That's a typeshed bug which you can report here: https://github.com/python/typeshed (or better, submit a PR!).fabianhjr commentedon Jul 20, 2016
The error is:
EDIT: Ok, upon reading on typeshed I think I should open a PR over there. Thanks.
gvanrossum commentedon Jul 20, 2016
Yup, that has nothing to do with the issue here: even though the error message is superficially the same, the cause is unrelated.
JukkaL commentedon Jan 16, 2017
More generally, module aliases aren't supported:
ilevkivskyi commentedon May 17, 2018
The module aliasing now works, but iterating over list of modules seems like a very low priority. Also this is superseded by python/typeshed#2147