Pyright (and Pylance) use two primary mechanisms to discover relevant import resolution paths: 1. We invoke the default Python interpreter and run a tiny script that simply returns the sys.path list. (Note: We need to be very careful when we do this to avoid executing arbitrary code on the user's machine without their knowledge or consent. This means the script cannot import any library other than `os` or `sys` because modules with names other than `os` and `sys` can be overridden by local source files.) The resulting list of paths includes site-packages, PYTHON_PATH additions, paths to zip files, and directories referred to by pth files. 2. We allow users to manually specify additional import resolution paths using an "extraPaths" configuration option. These are searched after the paths retrieved from sys.path. We discourage users from dynamically manipulating sys.path in their code because we cannot statically discover such manipulations. In rare cases where this cannot be avoided (typically in legacy code bases), we tell users to manually specify these paths using the "extraPaths" mechanism. Import hooks that dynamically manipulate or override sys.path in code present similar problems for tools that need to understand import resolution. I presume that other type checkers, language servers, and linters do something similar to Pyright as described above? Paul, you asked about zip files. Pyright handles these just like any other directory provided in sys.path. It uses a zip library to traverse the directory and file structure rather than making direct file system calls, but there's no other special casing involved in locating the zip file because its location is provided in sys.path. Bernat, if my assumption is correct that all static tools use a mechanism similar to Pyright, it would be convenient if the Python interpreter knew about additional import paths and added these to the sys.path list at startup. This would eliminate the need for the entire Python tooling ecosystem to understand yet another mechanism for discovering import resolution paths. More importantly, it would keep the knowledge of this mechanism in one place. Is that a possibility? There's still a small window of opportunity to get such a change into Python 3.11. The alternative is to standardize some now mechanism (presumably through a new PEP) that allows library authors to specify additional import resolution paths. As you suggested, this could be an addition to "py.typed" or some other new file that is included with the package. The downside to this approach is that it would need to be adopted by every static type checker, language server, IDE, linter, and other static analysis tool. This would be a costly solution that could take years to roll out completely. And depending on the complexity of the file format and its contents, it could take much longer to eliminate the bugs and other idiosyncrasies in all of these implementations. I'm hoping we can avoid this. Another option is to simply fall back on manual specification of import resolution paths within each tool (e.g. the "extraPaths" configuration option in Pyright). This would be a burden on users and would eliminate most of the convenience benefits of PEP 660. It would likely present a major hurdle for the adoption of PEP 660, so this option isn't very appealing either. -Eric -- Eric Traut Contributor to Pyright & Pylance Microsoft