Protocol.__call__与Callable的差异：回调类型定义抉择考量

在选择用Callable还是Protocol定义回调类型时，主要需要考量以下细微差别：

• 扩展能力的差异

  • Callable只能描述单一的调用签名，没法给回调对象附加额外的要求。如果后续需要回调支持其他方法（比如cleanup()）或者属性，Callable完全做不到，只能重新定义类型。
  • Protocol可以把__call__和其他方法/属性放在同一个契约里，相当于给回调对象定义了一个完整的接口。比如你可以在Callback协议里加个identifier: str属性，要求所有回调实例必须包含这个属性，扩展性拉满。

• 类型检查的严格程度

  • Callable对调用签名的匹配比较宽松，比如允许传入带默认参数的函数。假设你定义的是Callable[[Widget], Result]，传入一个接受Widget和一个可选参数的函数，类型检查器通常不会报错——虽然逻辑上run_thing只会传一个参数，不会有问题，但如果你想严格限定回调只能接受一个位置参数，Callable做不到。
  • Protocol的__call__方法可以精确控制参数规则，比如用/指定位置参数，或者明确禁止默认参数，类型检查工具会严格按照这个定义校验，避免不符合预期的回调被传入。

• 语义表达与可读性

  • Callable适合简单场景，代码简洁，一眼就能看懂是个接受Widget返回Result的函数，但语义上只是个函数类型，没法体现“回调接口”的意图。
  • Protocol用类的形式定义，语义上更像一个需要遵守的契约，其他开发者一看就知道这是个回调接口，必须实现__call__方法，在大型项目里可读性和维护性更好。

• 泛型支持的便捷性

  • Callable处理泛型会很繁琐，比如要定义一个支持泛型返回值的回调，写法会很绕。
  • Protocol可以直接结合泛型使用，比如：

    class Callback(typing.Protocol[T]):
        def __call__(self, w: Widget) -> T:
            ...
    

    这样就能轻松实现支持任意返回类型的回调契约，灵活性更高。

• 简单场景的便捷性

  • 如果只是基础的回调需求，不需要扩展，Callable的写法更省事，一行代码就能搞定，不需要额外定义类。
  • Protocol哪怕只需要__call__方法，也要写一个类结构，代码量稍多，但换来了更强的未来扩展性。

内容的提问来源于stack exchange，提问作者LudvigH