Pyright 在大型代码库中出现挂起或失败

我遇到了与 types.py 文件相关的 #10910 问题，该文件由 Prisma-client-py 生成。在某些语句之后，导出的类型被推断为 Unknown，导致类型检查在各个地方失败。因此，我尝试了 @erictraut 提议的方法：> 如果你希望使用 pyright，你需要降低复杂度，将其分解为多个模块。由于它是自动生成的，因此修改生成脚本以生成多个子模块而不是一个巨大的模块应该是很简单的。

PR: https://GitHub.com/Significant-Gravitas/Prisma-client-py/pull/1 我做的是将 Prisma.types 分成每个 DB 模型一个文件。这些文件之间仍然存在关系，但我修改了生成器，只导入当前模块实际引用的兄弟模块。 结果是，Pyright 现在在尝试分析依赖模块时 卡死，没有明确的迹象表明原因或具体问题是什么。看起来我们代码库的总复杂度正在阻碍 Pyright，其中一些模块的依赖图太大（例如 backend.data.graph），因此它们在单独分析时会导致卡死，而一些模块的复杂度太小，仍然可以正常工作（例如 backend.data.onboarding）。这也意味着我无法提供一个最小的可重现示例：那将是我们目前的代码库。 这是一个糟糕的情况，原因很明显。静态类型检查是我们在发生问题之前捕获和防止问题的重要部分。类型检查器 - 显然 - 具有限制，而且还不清楚我们如何修改项目以保持在这些限制内。 如果以下情况发生，将会非常有帮助：- Pyright 能够提供足够详细的日志，以便我可以看到它卡死的位置和原因- Pyright 可以发出消息，指出它拒绝分析超出其限制的模块- Pyright 可以配置更高的限制- Pyright 的限制附带了更清晰的说明，说明如何保持在限制内 这些情况都不存在，这使我无法明确地解决我遇到的问题。 @erictraut 您能帮助我们解决这个问题吗？我很乐意为 Pyright 贡献，但目前我甚至不知道该从何处开始解决这个问题。请让我知道您的想法和我如何能够帮助。 最初由 @Pwuts 在 #10910 中发布