PEP 827：类型操作（2026年Python语言峰会）
内容提要
PEP 827在2026年Python语言峰会上被讨论，提议为类型注解引入条件类型、推导类型和成员类型等原语，使返回类型可由输入参数推断，并自动生成CRUD模型类型。核心争议在于运行时如何存储类型注解：可选字符串格式、仅存字符串再eval，或使用__annotate__闭包，需权衡内存与速度。
延伸解读
PEP 827 的实用价值：从 ORM 到 CRUD 的类型自动化
PEP 827 旨在让 Python 类型注解支持条件类型、推导类型和成员类型等原语，从而根据输入参数推断返回类型，并自动生成 CRUD 模型类型。例如，在 ORM 中，可以根据查询参数推断出返回对象的类型；对于 CRUD 应用，可以基于一个基础模型自动生成用于创建、读取和更新的类型，减少手动维护多个模型的工作量。这有助于提升代码的简洁性和一致性，但具体实现和采用程度尚待观察。
运行时类型注解存储：内存与速度的权衡
PEP 827 讨论的焦点之一是如何在运行时存储类型注解。可选方案包括：直接存储字符串（速度快但内存占用高）、仅存字符串并在需要时用 eval() 求值（节省内存但速度慢），以及使用 __annotate__ 闭包。这些方案需要在内存和速度之间做出权衡，同时还要考虑对局部变量的引用。目前 PEP 倾向于支持 __annotate__ 函数，但具体实现细节仍在讨论中。
类型系统的图灵完备性与用户可见性
在峰会讨论中，有人问及 PEP 827 是否会使类型系统图灵完备。Michael 回应称 Python 类型系统已经意外地图灵完备，PEP 827 只是使其有意为之。此外，Łukasz Langa 提醒核心开发者不要对复杂语法产生本能反感，因为这些特性主要供框架内部使用，普通用户很少需要编写。但 David Hewitt 担心用户可能会在 API 中遇到复杂类型，Michael 承认在某些情况下用户会看到复杂类型，但希望通过文档字符串和语言服务器缓解。
Q&A
PEP 827 是什么？它主要想解决什么问题？
PEP 827 是一个关于 Python 类型注解改进的提案，在 2026 年 Python 语言峰会上讨论。它提议引入条件类型、推导类型和成员类型等原语，使返回类型能根据输入参数推断，并支持自动生成 CRUD 模型类型，从而减少手动维护重复模型的工作。
PEP 827 提出了哪些类型操作原语？
PEP 827 引入了条件类型（true_type if bool_type else false_type）、推导类型（*[t for t in Iter[iter_t]]，可带 if 条件）和成员类型（typing.Members[t] 返回类型成员的迭代器，成员有 name 和 type 属性）。此外还包含新运算符、可调用特殊构造、元组切片与长度、联合类型迭代等特性。
PEP 827 如何帮助简化 CRUD 应用中的模型定义？
在 CRUD 应用中，通常需要为每个操作（创建、读取、更新）定义单独的 ORM 模型，并保持与数据库模型同步。PEP 827 允许通过类型转换（如 Public[Hero]、Create[Hero]、Update[Hero]）自动生成这些模型类型，将复杂性封装在类型注解中，减少手动维护。
PEP 827 在运行时存储类型注解方面有哪些争议和方案？
争议在于如何存储类型注解以供运行时使用。方案包括：1) 使用字符串格式（Format.STRING），快速但内存冗余；2) 仅存储字符串，但需要环境闭包来 eval()，节省内存但速度慢；3) 使用 __annotate__ 闭包，权衡内存与速度。目前 PEP 设计支持通过调用 __annotate__() 函数来获取未求值的类型。
PEP 827 会使 Python 类型系统变成图灵完备吗？
Michael Sullivan 表示 Python 类型系统已经“意外地”图灵完备，接受 PEP 827 只会使其“有意地”图灵完备。他提到 Java 在泛型子类型边界上也遇到过类似问题，而 Python 的泛型机制与 Java 类似。
普通用户需要直接编写 PEP 827 的复杂类型语法吗？
不需要。Łukasz Langa 强调这些特性主要是供框架内部实现，让类型检查器能自动生成正确的类型。用户很少需要编写这样的类型，通常只在极少数情况下使用。Michael Sullivan 也承认用户可能会在 ORM 的 select 方法中看到复杂类型，但希望他们先看到文档字符串。
