Named tuples in import cycles still fail sometimes #4442
Comments
ilevkivskyi
added
bug
|
Somehow this breaks typshed build since recently, so I raised priority to high. |
This removes the circular dependency between the os and posix stub, which is somehow triggering python/mypy#4442. We should ideally fix the mypy bug, but since it's easy enough to fix the import cycle, we might as well do that too.
This removes the circular dependency between the os and posix stub, which is somehow triggering python/mypy#4442. We should ideally fix the mypy bug, but since it's easy enough to fix the import cycle, we might as well do that too.
This removes the circular dependency between the os and posix stub, which is somehow triggering python/mypy#4442. We should ideally fix the mypy bug, but since it's easy enough to fix the import cycle, we might as well do that too.
|
I deleted code from the typestub until I got, in from os import stat_result
# This was NamedTuple('etc'), but that doesn't affect the error.
uname_result = "dummy" # E: Invalid type "posix.uname_result" and in stat_result = "dummy"
from posix import T
def uname() -> uname_result: ...so there is something fishy with the way circular imports are resolved, but it doesn't seem to me to involve NamedTuple specifically. |
|
Actually, I think this is just a case of the bad circular import discussed in https://stackoverflow.com/a/40094439/5749914 (posix.py is Y.py, os/__init__.py is X.py) Mypy executes |
|
Do note that circular dependencies at run-time work differently than in
mypy's analysis.
|
|
Yes, but if it wouldn't work by python's runtime, I figure there is no reason to expect it to work for mypy, at least in this case IMO. |
|
@ilevkivskyi I think this ought to be closed because the behavior is reasonable, what do you think? |
|
@ilevkivskyi Can you come up with a self-contained example that reproduces the problem? I'd like to know if #4695 fixed this issue, and if not, I'll look at fixing this. |
OK, I will spend some more time now to find a simple repro for you. |
|
So, here is a simplest repro I can find: # file a.py
class C:
pass
from b import tp
x: tp
# file b.py
from a import C
from typing import NamedTuple
tp = NamedTuple('tp', [('x', int)])Then one needs to run Note that error disappears if Also note that the same error also appears if one or both of |
Fixes #5275 Fixes #4498 Fixes #4442 This is a simple _band-aid_ fix for `Invalid type` in import cycles where type aliases, named tuples, or typed dicts appear. Note that this is a partial fix that only fixes the `Invalid type` error when a type alias etc. appears in type context. This doesn't fix errors (e.g. `Cannot determine type of X`) that may appear if the type alias etc. appear in runtime context. The motivation for partial fix is two-fold: * The error often appears in stub files (especially for large libraries/frameworks) where we have more import cycles, but no runtime context at all. * Ideally we should refactor semantic analysis to have deferred nodes, and process them in smaller passes when there is more info (like we do in type checking phase). But this is _much_ harder since this requires a large refactoring. Also an alternative fix of updating node of every `NameExpr` and `MemberExpr` in third pass is costly from performance point of view, and still nontrivial.
It looks like issue #3054 was not completely fixed. Namely, in some scenarios named tuples
in import cycles result in
Invalid type. For example, checking this fileresults in
Note that the above "invalid" types are all named tuples and there is an import cycle
os <-> posix. Interestingly,import osandfrom os import *both typecheck cleanly.I haven't yet tried to find a simple repro (not involving typeshed).
The text was updated successfully, but these errors were encountered: