现在你被期望运行五个 Python 类型检查器了吗？

原文 ↗ Hacker News 讨论 ↗

分散的 Python 类型标注生态系统

  • 多个静态类型检查器（mypy、pyright、pyrefly/ty 等）造成了不兼容；库作者有时会同时运行几个，以避免用户看到类型错误。
  • 有些人认为这证明类型标注是后来硬加上的，原本就应该从语言/解释器一开始就纳入。
  • 另一些人认为同时运行许多检查器只是描述性而非规定性：这是当前碎片化的反映，不一定是在提出建议。
  • 有报告称每个检查器会捕捉不同类别的 bug（例如 overload vs. None 问题），因此尽管令人烦恼，双重使用仍有动机。

渐进式类型标注的价值与局限

  • 支持类型标注的评论：它能捕捉真实 bug，尤其是在大型/复杂代码库中；有助于 IDE、LSP 和文档；对他人使用的库/API 尤其有价值。
  • 批评者：注解通常冗长、无法推导，感觉像“带检查的注释”；动态特性更难使用；类型规范（例如收窄）定义不充分；有人认为相比测试几乎没有收益。
  • 有些人把 Python 的部分类型系统看作“最糟的两全其害”：你仍然要承担动态运行时成本，而且在运行时也无法完全依赖这些类型。

动态语言与静态类型语言

  • 一派观点：如果你想要严格类型系统，就转向 Rust/Go/C#/TypeScript，它们提供更好的性能、工具链和更干净的类型系统。
  • 另一派观点：迁移往往不可能（存量代码、ML/数据栈、客户端库），因此改进 Python 的类型系统仍然值得。
  • 还有人为动态语言辩护，认为它们高效且富有表现力；缺少类型带来的 bug 可以通过测试和良好纪律来控制，尤其是在 Web 框架中。

ML、生态与工具链

  • Python 在 ML/数据领域仍根深蒂固：NumPy/Pandas/ML 库以及预装可用性让它保持主导地位。
  • 有些人认为 LLM 辅助编码正在削弱 Python 的优势：静态语言加上强大的编译器能为人和代理提供更好的反馈。
  • 对工具链的抱怨包括打包、virtualenv 体验，以及越来越多的 lint/format/type-check 工具栈；也有人说 uv + ty/ruff 这类工具基本已经为他们解决了这些问题。

运算符重载与 __eq__

  • 围绕非布尔 __eq__ 结果的争论（数组、查询表达式、DSL）。
  • 有些人认为这很强大且可读（例如 dataframe 过滤器、ORM）；另一些人则把它看作一种“脚枪”，破坏了清晰性以及对相等性的预期。