如何为返回不同类型结果的函数列表进行准确类型标注

本文介绍在 Python 中为接受同一输入类型但返回多种不同输出类型的函数列表（如 Callable[[T], int]、Callable[[T], float] 等）进行合理类型标注的方法，重点解析为何不能使用单一泛型返回类型 U，以及如何通过 Any 或协议（Protocol）实现兼顾灵活性与类型安全的方案。

本文介绍在 python 中为接受同一输入类型但返回多种不同输出类型的函数列表（如 `callable[[t], int]`、`callable[[t], float]` 等）进行合理类型标注的方法，重点解析为何不能使用单一泛型返回类型 `u`，以及如何通过 `any` 或协议（protocol）实现兼顾灵活性与类型安全的方案。

在 Python 类型提示中，当一个函数接收多个可调用对象（*parse_functions），且这些可调用对象虽共享输入类型 T，却可能返回任意不相关的类型（如 int、str、datetime、自定义类等），直接使用泛型 U 进行统一标注会导致类型系统误判——因为 U 在函数签名中代表单一确定类型，而实际场景要求的是“返回类型不确定但可接受任意类型”。

例如，以下写法是错误的：

from typing import TypeVar, Callable

T = TypeVar("T")
U = TypeVar("U")

def try_parse(value: T, *parse_functions: Callable[[T], U]) -> U:
    ...

原因在于：Callable[[T], U] 要求所有传入的 parse_functions 必须返回完全相同的类型 U（由调用方推断），但现实中我们期望的是：
✅ 第一个函数返回 int，第二个返回 float，第三个返回 MyModel —— 它们互不兼容；
❌ 类型检查器（如 mypy）会报错：Argument 2 has incompatible type "Callable[[str], int]"; expected "Callable[[str], float]"。

✅ 推荐方案一：使用 Any（简洁、实用、符合动态语义）

最直接且语义准确的方式是将函数返回类型和最终结果类型均标注为 Any：

from typing import TypeVar, Callable, Any

T = TypeVar("T")

def try_parse(value: T, *parse_functions: Callable[[T], Any]) -> Any:
    for parse_function in parse_functions:
        try:
            return parse_function(value)
        except ValueError:
            continue
    raise ValueError(f"Cannot parse {value!r} with any of {parse_functions}")

✅ 优势：

创客贴设计

创客贴设计，一款智能在线设计工具，设计不求人，AI助你零基础完成专业设计！

下载

• 准确反映运行时行为：返回值类型取决于第一个成功执行的函数，无法静态预知；
• 兼容所有合法调用，无类型冲突；
• 与 typing.Any 的设计初衷一致——表示“类型未知但允许任何操作”。

⚠️ 注意事项：

• Any 会关闭对该返回值的后续类型检查（例如 result.upper() 不会报错，即使 result 实际是 int）；
• 若业务逻辑中能约束返回类型（如“所有解析器最终都返回 Union[int, float, str]”），应优先使用 Union 或更精确的类型。

✅ 推荐方案二：使用 Protocol 实现结构化约束（进阶、类型安全更强）

若需保留一定类型精度（例如明确要求所有解析器返回某种“可序列化”类型），可定义轻量协议：

from typing import TypeVar, Callable, Protocol, Union, overload

class Parsable(Protocol):
    def __call__(self, value) -> object: ...  # 协议仅声明调用能力，不限定返回类型

T = TypeVar("T")

def try_parse(value: T, *parse_functions: Parsable) -> object:
    for f in parse_functions:
        try:
            return f(value)
        except ValueError:
            pass
    raise ValueError(f"Cannot parse {value!r}")

或进一步结合 @overload 提供更智能的调用提示（适用于固定数量解析器的场景），但对 *args 动态变长参数支持有限。

总结建议

最终选择应基于你的类型检查严格度需求与代码可维护性权衡：Any 不是妥协，而是对动态多态场景的诚实表达。