Python 类型存在一个预期问题
Python 的类型提示因制造一种“预期不匹配”而受到关注：它们看起来像内建类型系统，但如果不把 mypy 或 pyright 之类的外部工具接入编辑器、CI 或部署流程，就不会提供任何保证。评论者讨论 Python 是否应该提供更严格、可选的强制执行，类似于 TypeScript 或 Rust，并分享在大型遗留代码库中逐步引入类型标注时的实用策略与痛点，同时提到 Pydantic 或类似 Sorbet 的运行时检查库作为部分解决方案。关于静态类型在动态语言中的整体价值，意见分歧明显；一些人认为它能改善工具支持、重构安全性和更早发现 bug，另一些人则认为它只会增加冗长，却没有明确证据表明缺陷更少。
预期不匹配：类型提示与强制执行
- 许多人认为存在一种不匹配：类型提示属于标准库和语法的一部分，但 CPython 在运行时会忽略它们，而且默认不会运行任何检查器。
- 有些人认为 Python 从来就不打算自带完整的类型检查器；外部工具（mypy、pyright）才是实际可行的方案，类似于 TypeScript 编译器。
- 另一些人希望有一种“严格”模式或包装器模式，在执行前先运行类型检查器，尤其适用于部署场景（例如在 Kubernetes 启动时快速失败，而不是在运行时失败）。
版本、错误与工具链
- 在较旧的 Python 上使用更新的类型语法（例如
dict[int, int]）会产生令人困惑的运行时错误（“type object is not subscriptable”）。 from __future__ import annotations并不能完全解决这个问题；仍然存在边缘情况 bug 和晦涩的行为。- IDE（VS Code、PyCharm）通常会利用类型提示来提供补全，但覆盖并不完整，而且经常依赖 stub 包。
对遗留代码库的渐进式类型标注
- 在大型、未做类型标注的代码库中引入 typing 被认为很痛苦：
- 在整个仓库上运行 mypy 会产生无法管理的错误洪流，因此 CI 检查常常被忽略。
- “种子文件”方法（手动列出要进行类型检查的文件）会增加摩擦和 CI 波动。
- 建议的策略包括：使用 mypy 的按模块配置，起初禁用导入跟踪，先给叶子模块加类型标注，然后逐步提高严格度。
- pre-commit 的 mypy 钩子被认为太慢且过于打扰；只在 CI 中运行更受欢迎。
表达能力与运行时用途
- Python 可以建模复杂行为：联合类型、重载、TypeVar 和递归类型，但通常需要冗长的模式（
@overload、大量 stub 集合）以及一些实际限制。 - 有些人在运行时使用注解（例如 Pydantic、自定义 JSON/dataclass 加载器、严格类型库），但这更慢，并非官方设计目标。
类型标注与生产力之争
- 一派认为 Python 中的静态类型会增加样板代码、拉长开发时间，并且可能导致每个功能产生更多 bug；他们认为大多数 bug 都是行为性 bug，最终仍需要测试，而且 Python 的 typing 对超大型单体项目来说不够强。
- 另一派强烈反对，举出大型类型化 Python 代码库的例子，认为注解提升了可读性、IDE 支持、重构能力，并能更早发现真实 bug。
- 关于 bug 率和 typing 效果的经验性说法存在争议；线程中没有给出明确共识或决定性证据。
文档与行内注解
- 有些人更喜欢丰富的 docstring（或基于注释的提示）而不是行内类型语法，因为这样更易读，希望“纯代码”把类型作为次要元数据。
- 另一些人认为最佳实践是两者都用：行内提示用于工具和快速理解，docstring 用于更高层次的语义。