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 have these two modules that form an import cycle:
# a.py
from collections import namedtuple
from b import f
N = namedtuple('N', 'a')
class X(N):
pass
# b.py
import a
def f(x: a.X) -> None:
reveal_type(x) # a.X
y = a.X(1)
reveal_type(y) # Tuple[Any, fallback=a.X]
The revealed types for two values with the same type a.X differ depending on how the type was constructed (see the comments above). The explanation is that when mypy processes the type annotation of f, is doesn't yet know that it is a named tuple type. The type of a.X(1) is determined later during type checking, and mypy then knows that it's a named tuple.
Not sure what's the best way to fix this. We could perhaps fix up named tuple types in the third pass of semantic analysis when this knowledge is available.
The text was updated successfully, but these errors were encountered:
Forward references didn't work with anything apart from classes, for example
this didn't work:
```
x: A
A = NamedTuple('A', [('x', int)])
```
The same situation was with `TypedDict`, `NewType`, and type aliases. The
root problem is that these synthetic types are neither detected in first pass,
nor fixed in third pass. In certain cases this can lead to crashes (first six issues
below are various crash scenarios). This fixes these crashes by applying some
additional patches after third pass.
Here is the summary of the PR:
* New simple wrapper type `ForwardRef` with only one field `link` is introduced
(with updates to type visitors)
* When an unknown type is found in second pass, the corresponding
`UnboundType` is wrapped in `ForwardRef`, it is given a "second chance" in
third pass.
* After third pass I record the "suspicious" nodes, where forward references and
synthetic types have been encountered and append patches (callbacks) to fix
them after third pass. Patches use the new visitor `TypeReplacer` (which is the
core of this PR).
Fixes#3340Fixes#3419Fixes#3674Fixes#3685Fixes#3799Fixes#3836Fixes#3881Fixes#867Fixes#2241Fixes#2399Fixes#1701Fixes#3016Fixes#3054Fixes#2762Fixes#3575Fixes#3990
I have these two modules that form an import cycle:
The revealed types for two values with the same type
a.X
differ depending on how the type was constructed (see the comments above). The explanation is that when mypy processes the type annotation off
, is doesn't yet know that it is a named tuple type. The type ofa.X(1)
is determined later during type checking, and mypy then knows that it's a named tuple.Not sure what's the best way to fix this. We could perhaps fix up named tuple types in the third pass of semantic analysis when this knowledge is available.
The text was updated successfully, but these errors were encountered: