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
I ran into this error too, there appears a need to add the ability to deal with a dot here in the parse unfortunately, I'm not sure what that would mean for the rest of the import code which will need to support it.
I guess anybody can finish the implementation, as it seems that @mason-bially is no longer working on this. If nobody else picks this up, I might work on this in the next couple of weeks, since this is a pretty major missing feature.
I am working on this now. I burned out during the period I was working on this due to other projects. I've had almost passing code in my repo for ages. I'm cleaning this up ASAP, apologies.
I'm running today's version from git (both globally and in the virtualenv) from mypy (just started, but so far love the project!), still get error with relative imports.
(.virtualenv)#reinoud@g ~/work/config 12:25:38 > ls -1
__init__.py
constants.py
devicetracker.py
fileimporter.py
mongo.py
website.py
(.virtualenv)#reinoud@g ~/work/config 12:25:44 > mypy --verbose __init__.py
__init__.py, line 1: No module named '__main__'
__init__.py, line 1: Module has no attribute 'mongo'
__init__.py, line 2: No module named '__main__'
__init__.py, line 2: Module has no attribute 'devicetracker'
__init__.py, line 3: No module named '__main__'
__init__.py, line 3: Module has no attribute 'website'
__init__.py, line 4: No module named '__main__'
__init__.py, line 4: Module has no attribute 'constants'
__init__.py, line 5: No module named '__main__'
__init__.py, line 5: Module has no attribute 'fileimporter'
__init__.py, line 9: Name 'mongo' is not defined
__init__.py, line 9: Name 'devicetracker' is not defined
__init__.py, line 9: Name 'website' is not defined
__init__.py, line 9: Name 'constants' is not defined
__init__.py, line 9: Name 'fileimporter' is not defined
This seems to be an error related to relative imports in the main package. It might be conflicting with the fact that the main package is also an __init__ file.
For a temporary fix, try using a separate main file which imports the library?
So I originally suspected this. The use case you are trying is not supported by python.
Consider:
$ python __init__.py
Traceback (most recent call last):
File "__init__.py", line 1, in <module>
from . import foo
SystemError: Parent module '' not loaded, cannot perform relative import
The temporary fix I proposed should work correctly. I'm assuming you already have a main script which imports and uses the module with the __init__.py file anyway, run mypy on that.
Although it might be worth fixing relative imports to support this behavior simply for usability, but that would be an additional feature (in my opinion).
Right, this makes sense. I guess that's why there is an -m option on the executable to check modules.
I am hoping to convince my editor to check each file each time I save it, guess I should accept that not working in this case. Would indeed be nice to have at some point, but I see how this is not top priority now.
Unfortunately, I believe the correct way to do that at the moment is to check the whole project from the beginning every time (i.e. from the root main.py file). Theoretically you would need some sort of resume-able type checking structure to accomplish an IDE style type checker without doing that.
Since I'm not actually part of the team maintaining this project I don't know what the plans are for that.
Mypy should probably support type checking any file within a package, instead of having to start from a top-level module or having to use -m modname. For example, assume I have files like this:
I just hit this while fixing the test script to actually test everything, not just a subset.
It is unrelated to which module is the "main" module. Rather, it seems that relative imports are supported in __init__.py at all, because it thinks that e.g. requests doesn't have a parent module at all.
Activity
JukkaL commentedon Jul 15, 2014
Also
from . import xdoes not work.mason-bially commentedon Aug 14, 2014
I ran into this error too, there appears a need to add the ability to deal with a dot here in the parse unfortunately, I'm not sure what that would mean for the rest of the import code which will need to support it.
mason-bially commentedon Aug 14, 2014
Would need to expand this node (and the one below) to deal with it, likely a relative file-name (or just a bool if it's available elsewhere in the tree).
Adding relative import support (python#60)
JukkaL commentedon Dec 3, 2014
I guess anybody can finish the implementation, as it seems that @mason-bially is no longer working on this. If nobody else picks this up, I might work on this in the next couple of weeks, since this is a pretty major missing feature.
Adding relative import support (python#60)
mason-bially commentedon Dec 5, 2014
I am working on this now. I burned out during the period I was working on this due to other projects. I've had almost passing code in my repo for ages. I'm cleaning this up ASAP, apologies.
Fixing issues with semantic analysis of relative imports (python#60).
Fixing issues with semantic analysis of relative imports (python#60).
JukkaL commentedon Dec 7, 2014
Relative imports work now!
reinhrst commentedon Feb 19, 2015
I'm running today's version from git (both globally and in the virtualenv) from mypy (just started, but so far love the project!), still get error with relative imports.
My
__init__.pyreads:result:
Anything obvious I'm missing?
mason-bially commentedon Feb 19, 2015
This seems to be an error related to relative imports in the main package. It might be conflicting with the fact that the main package is also an
__init__file.For a temporary fix, try using a separate main file which imports the library?
mason-bially commentedon Feb 19, 2015
So I originally suspected this. The use case you are trying is not supported by python.
Consider:
The temporary fix I proposed should work correctly. I'm assuming you already have a main script which imports and uses the module with the
__init__.pyfile anyway, run mypy on that.Although it might be worth fixing relative imports to support this behavior simply for usability, but that would be an additional feature (in my opinion).
reinhrst commentedon Feb 19, 2015
Right, this makes sense. I guess that's why there is an
-moption on the executable to check modules.I am hoping to convince my editor to check each file each time I save it, guess I should accept that not working in this case. Would indeed be nice to have at some point, but I see how this is not top priority now.
mason-bially commentedon Feb 20, 2015
Unfortunately, I believe the correct way to do that at the moment is to check the whole project from the beginning every time (i.e. from the root
main.pyfile). Theoretically you would need some sort of resume-able type checking structure to accomplish an IDE style type checker without doing that.Since I'm not actually part of the team maintaining this project I don't know what the plans are for that.
JukkaL commentedon Feb 20, 2015
Mypy should probably support type checking any file within a package, instead of having to start from a top-level module or having to use
-m modname. For example, assume I have files like this:Now all of these should work:
I need to think about this a bit more, though.
o11c commentedon Jul 2, 2015
I just hit this while fixing the test script to actually test everything, not just a subset.
It is unrelated to which module is the "main" module. Rather, it seems that relative imports are supported in
__init__.pyat all, because it thinks that e.g.requestsdoesn't have a parent module at all.o11c commentedon Jul 2, 2015
Actually, it looks related to the
.pyichanges, I've gotten past that error now.Now to fix the actual bugs in the stubs that weren't being tested ...