Typeshed import cycle causes mypy to start claiming a fixed-length tuple type alias declared with TypeAlias
is "not valid as a type"
#16581
Labels
affects-typeshed
Anything that blocks a typeshed change
bug
mypy got something wrong
topic-import-cycles
topic-type-alias
TypeAlias and other type alias issues
Bug Report
We're having a bit of trouble over in python/typeshed#11074. It seems like it's impossible to import
importlib.readers
insidestdlib/importlib/machinery.pyi
and also usetyping_extensions.TypeAlias
to explicitly demarcate type aliases insidestdlib/zipfile.pyi
. The cause appears to be a huge import cycle in our stubs for the standard library:importlib.machinery
importsNamespaceReader
fromimportlib.resources.readers
importlib.reasources.readers
importszipfile.Path
fromzipfile
zipfile
importsTypeAlias
fromtyping_extensions
typing_extensions
importsget_original_bases
fromtypes
types
importsModuleSpec
fromimportlib.machinery
... and we're back at the beginning.As a workaround, things seem to work fine for us if we just don't use
typing_extensions.TypeAlias
for the problematic alias inzipfile.pyi
. But this behaviour from mypy seems buggy, so I figured it would be good to file a bug.To Reproduce
I haven't been able to reproduce this issue outside of the typeshed context. However, I have reduced typeshed down to a "minimum viable typeshed" required to reproduce the bug (https://github.com/AlexWaygood/typeshed/tree/mypy-import-cycle-repro/stdlib). Here are the repro steps:
mypy-import-cycle-repro
branch of the repopip install -r requirements-tests.txt
python tests/mypy_test.py stdlib -p3.12
Expected Behavior
Mypy handles the import cycle -- or at least gives an intelligible error reporting what the problem is.
Actual Behavior
Your Environment
The text was updated successfully, but these errors were encountered: