Hi Bernat and Paul, Apologies for the late response. And thank you so much for bringing up this issue onto the typing-sig mailing list! As one of the maintainers of the Pyre type checker, I agree with Eric's statement that import hooks are way too dynamic for static analyzers to handle. I want to re-emphasize the point here that static checkers and similar language toolings cannot run arbitrary Python code for import resolution, regardless of whether the said code lives in Python's stdlib or not. Many type checkers (such as Pyright and Pyre) are themselves not written in Python. And even for type checkers that are written in Python, they are often used to type-check projects that needs to be executed in a different Python venv/interpreter. In most cases, "invoke that import hook that happens to be shipped with Python" is just not an option for us. The only sensible way for static tooling to support a new dynamic import hook is to replicate the entire logic of that hook within the tool itself. This requires a lot of work and also implies heavy maintenance burden on our side. The alternative solution, i.e. emitting a static project layout where we explicitly specify how to get the source content for each and every module, would be much better for us than the dynamic import approach. But even supporting this approach would be tricky. In addition to the concern Eric raised before, the other issue I want to point out is how to implement efficient incremental checks: Static analyzers and IDE tooling typically do not re-analyze the entire project every time the users hit "save" in their editors -- what happens instead is that we rely on some sort of filesystem watcher to let us know which files have been added/changed, and only re-analyze the added/changed files while re-using the cached analysis results for unchanged files. If we were to allow additional modes to get the sources, we would need to think of a way to figure out, e.g., when would a source file that come from a database/network can change (periodically scanning for changes, as Bernat suggested, does not scale well for large projects). This is not impossible to do, but it also requires tons of engineering to get right, and I am skeptical on whether such engineering effort is worth it, given that the vast majority of Python users do not need to grab sources from anywhere other than the filesystem. I hope my explanation above could provide you with additional context on why the additional flexibilities on import resolutions is problematic for us: The more flexible&dynamic the mechanism is, the more engineering burden we will get as authors of static analyzers. In an ideal world with unlimited time&resources, this might not be an issue. But the reality is that resources are scarce for us, and we do have other priorities such as maintaining&evolving the Python type system. My guess is that solutions with pre-existing mechanisms like `pth` files would be a path forward with least resistance for this community. Proposing some kind of static layout format that only allows filesystem imports would be a suboptimal but (barely) acceptable approach. Anything beyond that would be difficult to push for adoption. - Jia