-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Circular import of name defined in same module, reported as an error. #12574
Labels
Comments
hauntsaninja
added a commit
that referenced
this issue
Nov 3, 2022
This changes our importing logic to be more consistent and to treat import statements more like assignments. Fixes #13803, fixes #13914, fixes half of #12965, probably fixes #12574 The primary motivation for this is when typing modules as protocols, as in #13803. But it turns out we already allowed redefinition with "from" imports, so this also seems like a nice consistency win. We move shared logic from visit_import_all and visit_import_from (via process_imported_symbol) into add_imported_symbol. We then reuse it in visit_import. To simplify stuff, we inline the code from add_module_symbol into visit_import. Then we copy over logic from add_symbol, because MypyFile is not a SymbolTableNode, but this isn't the worst thing ever. Finally, we now need to check non-from import statements like assignments, which was a thing we weren't doing earlier.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I have a project, which I've reduced to a minimum which shows the same problem. It has 9 modules, excerpts are:
The other modules, with the above, form an SCC of imports, so all 9 are analyzed together.
Expected Behavior
solver\debugging.py:12:2: error: Module "solver.instruct" has no attribute "InstrTab"
The InstrTab import is an error because the name does not exist in the imported module.
The class def of
InstrCtx
should be OK, since the import fromcommon
is importing the same thing.Actual Behavior
Discussion
In some cases, a circular import would be a programming error, as the runtime results could vary depending on which of the modules in the SCC is imported first.
In my case, the import in
solver.debugging
is guarded byTYPE_CHECKING
, and so it has no effect at runtime. mypy makes a placeholder forsolver.debugging.InstrCtx
, then later this is imported intosolver.instr_common
as aVar
object.Now if the placeholder resulted from a guarded import, then mypy should not consider that
InstrCtx
is imported at runtime, and so it should be ignored.In effect, the import of
solver.debugging.InstrCtx
is private. It is not visible to other modules, and is visible withinsolver.debugging
only for type analysis purposes.I propose adding the following to
semanal.py
to make imported names non-public when MYPY-guarded:Attached is a zip file with:
log.txt
from mypy run before making changes.log2.txt
from mypy run after making changes.Exp3.zip
Your Environment
The text was updated successfully, but these errors were encountered: