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
"Invalid Type" error in v0.600 on uncached runs involving file with same name as parent package #5015
When I run mypy on my project, I sometimes get an invalid type error. This error seems to go away over time (some kind of caching issue?), or if I avoid having a file in a package of the same name, or if I do an explicit direct import of the type from the file instead of importing it via the package.
This is kind of a complicated bug to reproduce, but here is my best attempt at making a succinct repro. We will need five files.
Create a fresh virtual environment and test project directory.
project/neighbor/__init__.py:4: error: Invalid type "project.study.study.CustomType"
If you run mypy again without clearing its cache, then there will be no error.
or, depending on factors I don't understand you may get this different error instead:
project/neighbor/__init__.py:2: error: Internal error (node is None, kind=1)
An easy workaround for this issue is to avoid defining types in files that have the same name as their parent directory. Everyone likes avoiding cache invalidation issues by naming things, right?
changed the title [-]"Invalid Type" error on uncached runs involving file with same name as parent package[/-][+]"Invalid Type" error in v0.600 on uncached runs involving file with same name as parent package[/+]on May 8, 2018
This introduced many errors when switching from 0.590 to 0.600 on some proprietary code base at $DAYJOB. I verified that the fix from the import-cycles branch fixes all these issues #5016
The situation that we have is the following (I couldn't reproduce a minimal example). A being a module and a a submodule:
A
a
b
B
a
b
A.a import B.b and B.b imports A.a. So there is no cycle at the submodule level.
It could be, the package has many sub modules and sub-sub modules depending on each other (needs refactoring :)), though no direct cycles. I can't produce a repro unfortunately.
However this PR fixed it all #5016
Activity
[-]"Invalid Type" error on uncached runs involving file with same name as parent package[/-][+]"Invalid Type" error in v0.600 on uncached runs involving file with same name as parent package[/+]JelleZijlstra commentedon May 8, 2018
Thanks for the detailed reproduction instructions!
gvanrossum commentedon May 8, 2018
Hm, I wonder what the cache contents are for those five files?
msullivan commentedon May 8, 2018
I was able to get this error to appear (including follow up internal errors) even if I renamed the submodule?
msullivan commentedon May 8, 2018
Bisecting shows that this is a regression from 0.590 introduced by #4910. I'll take a look.
Restore `all_are_submodules` import logic as workaround for #4498
thomascellerier commentedon May 14, 2018
This introduced many errors when switching from 0.590 to 0.600 on some proprietary code base at $DAYJOB. I verified that the fix from the
import-cyclesbranch fixes all these issues #5016The situation that we have is the following (I couldn't reproduce a minimal example).
Abeing a module andaa submodule:A.aimportB.bandB.bimportsA.a. So there is no cycle at the submodule level.JelleZijlstra commentedon May 14, 2018
Is your issue the same as #5024?
thomascellerier commentedon May 14, 2018
It could be, the package has many sub modules and sub-sub modules depending on each other (needs refactoring :)), though no direct cycles. I can't produce a repro unfortunately.
However this PR fixed it all #5016