Type Server Protocol
Microsoft 为 Python 推出的新 Type Server Protocol（TSP）旨在标准化 VS Code 等编辑器与外部类型检查器的通信方式，让 Pylance 和第三方分析器能够通过统一接口互换。评论者看法分裂：一部分人欢迎这种机器可读、结构化的类型 API，以及“自带类型检查器”的可能性；另一部分人则认为 TSP 是不必要的、Python 特定的协议，本应只是现有 Language Server Protocol 的扩展，并且可能被用来加深对 Microsoft 生态的锁定。讨论很快又延伸到对 Python 的类型系统、打包和性能的长期不满，以及在 AI 辅助开发和更强静态类型系统时代，动态语言是否仍然有意义。
TSP 是什么以及它为何存在
- 被描述为一种协议，使 Pylance 能将 Python 类型检查委托给外部“类型服务器”（例如 Pyrefly、Ty），而 Pylance 继续作为 LSP 前端。
- 提供机器可读的“某点类型”以及其他结构化类型查询，比典型的 LSP hover/signature 字符串更详细。
- 线程中提到的目标是标准化类型检查，这样你就可以“自带”检查器，同时保留 VS Code 集成。
范围与命名
- 多位评论者指出它虽然名字泛化，但实际上是 Python 特定的；有人认为它应该明确命名为 Python Type Server Protocol。
- 有人好奇它是否能推广到其他动态类型语言，但目前的 schema 被认为非常以 Python 为中心。
技术设计与 LSP 的关系
- 大体被视为通过 JSON-RPC、带有 Python 特定 schema 的 LSP 扩展，而不是从零开始的新协议。
- TSP 延续了 LSP 使用 UTF-16 位置的惯例；一些人批评这是一种由 VS Code 遗留驱动的设计，会让偏移处理更复杂。
- 也有人指出 LSP 3.17+ 可以协商编码方式，从而缓和这一批评。
生态系统与工具链影响
- 一个主要的类型检查器（basedpyright）公开拒绝支持 TSP，称其是不必要的复杂性，主要只会让 Microsoft 受益。
- 另一个（Ty，Ruff 的一部分）计划支持它，评论者认为这对于避免被锁定到 Pylance 的专有行为很重要。
- 一些人认为 TSP 有助于统一不同 IDE 的行为；另一些人已经更偏好直接集成（例如 Pyrefly 扩展），因为生态被分割。
对 Microsoft 策略的担忧
- 几篇帖子将 TSP 视为围绕 LSP 的“拥抱、扩展”策略，目的是让某些功能保持 VS Code/Pylance 独占，并拖慢向替代编辑器或服务器迁移的进程。
- 也有人认为，大公司开源工具往往主要是为了减轻自己的维护成本或吸引人才，而不只是单纯为了锁定用户。
关于 Python 与类型系统的更广泛观点
- 线程中还展开了关于 Python 设计的大量分支讨论：批评者称其设计不足、速度慢、打包负担重；支持者则强调易用性、生态系统以及在机器学习/科学领域的成功。
- 有人认为动态语言加渐进式类型最终是条死路，预计 AI 会推动语言转向更严格、静态类型更强的方向；也有人认为 Python 的势头使其会长期持续存在。