Python 3.15 新特性：sentinel 类型比 None 更好用？

Python 中 None 常被用来表示“没有值”，但它的语义其实非常模糊：值缺失、用户显式选择为空、非法输入……这些情况都可能被塞进同一个 None 里。Python 3.15 引入的 sentinel 类型，正是为了把这类“状态标记”从 None 和裸 object() 中解放出来。

为什么 None 不够用？

设想一个用户选择题场景：用户可以选择某个值，也可以显式地选择“什么都不选”。在字符串世界里，空选择可以用空字符串表示；在数字世界里，零和负一都是合法值，无法用它们来代表“空”。于是开发者通常求助于 None。

问题在于 None 承载了太多含义——它可能表示值从未被提供，可能表示用户刻意选择了空，也可能表示输入非法。当同一个函数返回值需要区分这些状态时，None 就失去了表达力。视频中的讲解者提出，我们需要的是一种哨兵（sentinel）数据类型，用来定义彼此独立的状态。

哨兵值（sentinel value） 是编程中一种特殊标记，用于在正常取值范围之外表示某种控制状态，例如“未找到”“未提供”或“循环结束”。它必须与所有合法数据值互不相等，典型实现是使用唯一对象。Python 标准库中已有类似实践，如 dataclasses.MISSING、inspect.Parameter.empty 和 re.Pattern 的 __sentinel__。哨兵的核心要求是唯一性与可识别性：调用方只需用 is 比较即可判断状态，而不会与用户数据混淆。理解这一点，就能明白为什么用 None 或 -1 充当哨兵会带来歧义。

sentinel 的基本用法

Python 3.15 允许直接创建带名字的哨兵对象，例如 missing = sentinel('missing')，再为“空选择”定义另一个 empty = sentinel('empty')。每个哨兵都是独立且唯一的对象，可以精确对应一种业务状态。

在这之前，社区常见的替代方案是 missing = object()——创建一个裸对象作为标记。这种做法虽然能保证唯一性，但存在明显短板。

类型提示（type hints） 是 Python 3.5 引入的静态类型标注机制，配合 mypy、pyright 等检查器在运行前发现类型错误。类型检查器把标注为 object 的参数视为接受任意值，因此用裸 object() 作哨兵时，函数签名无法表达“这里只接受某个哨兵或具体类型”。PEP 484 提供了 typing.Literal、typing.Final 和 typing.TypeGuard 等工具来描述特殊取值，但直到 sentinel 出现，语言层面才有一个既唯一又能被类型系统精确追踪的哨兵类型。这解释了为什么新类型能改善类型提示体验。

object() 作为哨兵的老问题

用 object() 做哨兵最大的麻烦出现在类型提示上。如果你把类型标注写成 object 或 type(missing)，类型检查器会认为这个参数接受任意类型，等于放弃了类型约束。此外，直接打印裸对象会得到一串无意义的内存地址标识，调试体验很差。

sentinel 的设计目标就是让这类标记更顺手：它保留唯一性，同时提供可读的名称，并在类型系统中拥有明确的身份，而不是退化成“什么都接受”的 object。

repr() 与调试可读性：Python 对象的默认字符串表示形如 <object object at 0x7f...>，只包含类型名和内存地址，对日志和交互式调试几乎没有信息量。良好的 repr() 应让开发者一眼看出对象身份，例如 sentinel('missing') 可以显示为 <sentinel missing>。这正是 sentinel 相比裸 object() 的实用改进之一：它让哨兵在报错信息、调试器和 REPL 中自带语义标签，减少排查成本。

对日常代码的影响

这项改动的价值不在于语法糖，而在于让 API 契约更清晰。当一个函数需要区分“未传参”“显式传空”“传了非法值”三种情况时，过去往往要组合使用 None、特殊字符串或自定义类，现在可以用一组语义明确的哨兵来表达。对于编写库、SDK 或带默认参数的业务接口，这种表达力的提升尤其明显。

从设计哲学上看，sentinel 延续了 Python 对“显式优于隐式”的追求：与其让 None 承担多重职责，不如为每种状态起一个名字。对于长期受困于 None 歧义的开发者来说，这可能是 Python 3.15 中最实用的小改动之一。