Specifically, if I apply this diff to my PR branch:

+    import importlib.readers
+
     class NamespaceLoader(importlib.abc.InspectLoader):
         def __init__(
             self, name: str, path: MutableSequence[str], path_finder: Callable[[str, tuple[str, ...]], ModuleSpec]
@@ -171,7 +173,7 @@ if sys.version_info >= (3, 11):
         # Actually get_resource_reader() returns importlib.readers.NamespaceReader.
         # Unfortunately, importing from importlib.readers in importlib.machinery
         # appears to break mypy's brain a little (probably due to a massive import cycle)?
-        def get_resource_reader(self, module: types.ModuleType) -> Incomplete: ...
+        def get_resource_reader(self, module: types.ModuleType) -> importlib.readers.NamespaceReader: ...
         if sys.version_info < (3, 12):
             @staticmethod
             def module_repr(module: types.ModuleType) -> str: ...

Then mypy starts issuing this (bizarre) complaint:

stdlib\zipfile.pyi:200: error: Variable "zipfile._DateTuple" is not valid as a type  [valid-type]
stdlib\zipfile.pyi:200: note: See https://mypy.readthedocs.io/en/stable/common_issues.html#variables-vs-type-aliases

After some investigation, it seems like the cause of the false positive is an import cycle between importlib, zipfile, typing_extensions and types:

• importlib.machinery imports imprtlib.resources.readers
• importlib.reasources.readers imports zipfile
• zipfile imports typing_extensions
• typing_extensions imports types
• types imports importlib.machinery

The false positive can be avoided if we don't explicitly mark zipfile._DateTuple as a type alias using typing_extensions.TypeAlias. So I've used that workaround instead, in 277ba41.

Off-topic, and outside the scope of this PR, but I wonder whether it would make sense to change the classes in importlib.abc to protocols. Although that's probably not possible, because they are also abcs.

It might also make sense to include create_module(), exec_module(), and load_module() here. While they are inherited in the stubs, they aren't in the implementation (since NamespaceLoader inherits directly from object).

It might also make sense to include create_module(), exec_module(), and load_module() here. While they are inherited in the stubs, they aren't in the implementation (since NamespaceLoader inherits directly from object).

Good shout. Done in a15d3cc!