本文详解如何通过类型注解与运行时断言协同实现 None 安全的类型精炼，提供符合 PEP 484 / PEP 647 规范的 not_none 工具函数，并对比 assert 与 raise 的适用场景及静态类型检查行为。
本文详解如何通过类型注解与运行时断言协同实现 `none` 安全的类型精炼，提供符合 pep 484 / pep 647 规范的 `not_none` 工具函数，并对比 `assert` 与 `raise` 的适用场景及静态类型检查行为。
在 python 类型驱动开发中，处理 Optional[T]（即 T | None）是最常见的类型精炼需求之一。虽然 assert val is not None 能在运行时拦截 None，但默认情况下，静态类型检查器（如 mypy、PyRight）不会将该断言视为类型守卫（Type Guard）——除非你显式声明其类型行为。为真正实现“一次编写、类型安全、DRY 友好”，推荐定义一个泛型工具函数：
✅ 正确的 TypeGuard 实现（兼容主流类型检查器）
from typing import TypeVar, Any T = TypeVar("T") def not_none(val: T | None, msg: str = "Value is None") -> T: if val is None: raise TypeError(msg) return val? 关键点：
- 参数类型为 T | None，返回类型为 T（非联合类型），向类型检查器明确传达「调用成功即意味着输入值已被精炼为非 None」；
- 使用 if val is None: raise … 而非 assert，因为 assert 在 -O 优化模式下被完全移除，导致类型精炼失效且无运行时保障；
- is None 比 not val 更安全——避免误判 0, False, [], “” 等 falsy 值。
? 使用示例
from typing import Optional data: Optional[str] = get_user_name() # 类型为 str | None # ✅ 安全提取并获得精确类型 str name: str = not_none(data, "User name must be provided") # 此后所有操作均被类型检查器识别为 str 类型 print(name.upper()) # ✅ 无报错 print(len(name)) # ✅ 无报错⚠️ 注意事项与最佳实践
-
不要滥用 assert 做类型精炼：assert val is not None 在类型检查中仅对 当前作用域内变量 生效（如上文答案所示），但无法跨函数传递精炼信息。例如：
x: int | None = maybe_get_int() assert x is not None process(x) # ✅ 此处 x 被推断为 int def guard(x: int | None) -> int: assert x is not None # ❌ 类型检查器不认为此函数具有 TypeGuard 行为 return x y: int | None = ... z = guard(y) # ❌ z 仍被推断为 int | None —— 类型未精炼！ -
TypeGuard 协议（可选进阶）：若需显式标注函数为类型守卫（例如用于 isinstance 风格逻辑），可使用 typing.TypeGuard（Python 3.10+）：
立即学习“Python免费学习笔记（深入）”；
from typing import TypeGuard def is_not_none(val: Any) -> TypeGuard[object]: return val is not None但注意：TypeGuard 仅适用于布尔返回值函数，且不改变参数类型（它描述的是 val 是否满足某类型条件），而 not_none() 是更实用的「精炼并返回」模式。
-
替代方案：直接内联精炼
对于简单场景，优先使用原生 if 或 assert + 类型检查器内置精炼能力，避免过度封装：if data is None: raise ValueError("data required") # 此后 data 在 mypy/PyRight 中自动被视为 str（非 Optional[str]）
✅ 总结
- not_none(val: T | None) -> T 是简洁、安全、类型检查友好的标准模式；
- 用 raise 替代 assert 保证运行时可靠性与类型精炼一致性；
- 类型检查器（mypy ≥ 0.930、PyRight）原生支持 x is not None 精炼，但仅限语句级作用域；跨函数精炼必须依赖显式泛型返回类型；
- 该函数本质是「类型精炼函数（type-refining function）」，虽未标注 @overload 或 TypeGuard，但因签名设计符合类型系统推导规则，已被主流工具广泛支持。
遵循上述写法，你即可在保持代码清晰的同时，让类型检查器全程理解你的意图，真正实现「所见即所得」的类型安全。