理解可哈希与可排序的类型需求
在python中，某些数据结构（如集合的元素、字典的键）要求其内容是“可哈希的”（hashable）。一个对象可哈希意味着它有一个不变的哈希值，并且在生命周期内哈希值不会改变。这通常通过实现__hash__方法和__eq__方法来体现。typing模块提供了hashable抽象基类，用于类型提示。
另一方面，当我们需要对对象进行排序时，这些对象必须是“可排序的”（Orderable）。这意味着它们需要支持一系列比较操作，例如小于（__lt__）、小于等于（__le__）、等于（__eq__）、不等于（__ne__）、大于（__gt__）和大于等于（__ge__）。Python内置的sorted()函数或列表的sort()方法都依赖于这些比较方法来确定元素的顺序。
当一个函数需要一个既可哈希又可排序的参数时，如何为其提供一个准确且富有表达力的类型提示，是我们在编写高质量Python代码时需要解决的问题。
初步尝试与局限性
我们可能会尝试使用TypeVar并为其绑定Hashable来表示可哈希性：
from collections.abc import Hashable
from typing import TypeVar
# 这种方式只表达了可哈希性
OrderedHashable = TypeVar('OrderedHashable', bound=Hashable)
def foo(bar: OrderedHashable) -> None:
# 在这里，我们知道bar是可哈希的，但静态分析工具不知道它是否可排序
pass然而，这种方法存在明显的局限性。虽然OrderedHashable这个名字暗示了“有序”，但TypeVar的bound=Hashable仅仅保证了参数是可哈希的，并没有强制要求它实现任何排序相关的魔术方法（如__lt__或__gt__）。因此，静态类型检查工具无法识别bar是否支持比较操作。
使用 Protocol 定义复合类型
为了解决上述问题，Python的typing模块提供了Protocol。Protocol允许我们定义一个结构化的类型，即只要一个类实现了Protocol中定义的所有方法和属性，它就被认为是符合该Protocol的类型，而无需显式继承。这非常适合定义像“可哈希且可排序”这样的复合行为。
我们可以定义一个Protocol，它继承自Hashable，并额外声明__gt__和__lt__方法：
from typing import Hashable, Protocol, TypeVar
# 定义一个Protocol，表示既是可哈希的，又支持排序比较
class OrderedHashable(Hashable, Protocol):
"""
表示一个既可哈希又可排序的类型。
需要实现__hash__、__eq__（来自Hashable）以及__gt__、__lt__方法。
"""
def __gt__(self, other: "OrderedHashable") -> bool:
"""
定义大于操作 (self > other)。
"""
... # 省略具体实现，Protocol中只需声明签名
def __lt__(self, other: "OrderedHashable") -> bool:
"""
定义小于操作 (self < other)。
"""
... # 省略具体实现，Protocol中只需声明签名
# 使用TypeVar绑定这个Protocol，以便在泛型函数中使用
OrderedHashableT = TypeVar('OrderedHashableT', bound=OrderedHashable)
def process_ordered_hashable(item: OrderedHashableT) -> None:
"""
一个接受可排序且可哈希参数的函数。
"""
print(f"处理项: {item}")
# 静态类型检查工具现在知道item支持哈希和比较操作
_ = hash(item) # 可哈希
if item < item: # 可排序
pass
if item > item: # 可排序
pass
# 示例：定义一个符合OrderedHashable协议的类
class MySortableItem:
def __init__(self, value: int, name: str):
self.value = value
self.name = name
def __hash__(self) -> int:
return hash((self.value, self.name))
def __eq__(self, other: object) -> bool:
if not isinstance(other, MySortableItem):
return NotImplemented
return self.value == other.value and self.name == other.name
def __lt__(self, other: "MySortableItem") -> bool:
if not isinstance(other, MySortableItem):
return NotImplemented
return self.value < other.value
def __gt__(self, other: "MySortableItem") -> bool:
if not isinstance(other, MySortableItem):
return NotImplemented
return self.value > other.value
def __repr__(self) -> str:
return f"MySortableItem(value={self.value}, name='{self.name}')"
# 使用示例
item1 = MySortableItem(10, "Apple")
item2 = MySortableItem(20, "Banana")
process_ordered_hashable(item1) # 类型检查通过
process_ordered_hashable(item2) # 类型检查通过
# 尝试使用不符合协议的类型（例如，只可哈希但不可排序）
class JustHashable:
def __init__(self, value: int):
self.value = value
def __hash__(self) -> int:
return hash(self.value)
def __eq__(self, other: object) -> bool:
if not isinstance(other, JustHashable):
return NotImplemented
return self.value == other.value
# process_ordered_hashable(JustHashable(5))
# 上面的代码会在静态类型检查时报错，因为JustHashable没有实现__lt__和__gt__在这个解决方案中：
- OrderedHashable(Hashable, Protocol): 我们定义了一个名为OrderedHashable的Protocol。它继承自Hashable，这意味着任何实现OrderedHashable的类型都必须是可哈希的。同时，它也是一个Protocol，允许我们声明额外的结构化要求。
- __gt__(self, other: "OrderedHashable") 和 __lt__(self, other: "OrderedHashable"): 在Protocol内部，我们声明了__gt__和__lt__这两个魔术方法。这意味着任何被认为是OrderedHashable的类型，都必须提供这两个方法的具体实现。这里的other: "OrderedHashable"使用了前向引用，因为OrderedHashable本身正在被定义。
- OrderedHashableT = TypeVar('OrderedHashableT', bound=OrderedHashable): 我们继续使用TypeVar，但这次它的bound参数指向了我们新定义的OrderedHashable Protocol。这样做的好处是，process_ordered_hashable函数仍然是泛型的，可以接受任何符合OrderedHashable协议的具体类型，同时保留了该类型的特定信息。
注意事项与总结
- Protocol的强大之处: Protocol提供了一种“鸭子类型”（Duck Typing）的静态类型检查方式。只要一个类的结构（方法和属性）与Protocol定义相符，它就满足该Protocol，无需显式声明继承关系。这使得类型提示更加灵活和强大。
- 排序方法的完整性: 虽然示例中只包含了__lt__和__gt__，但为了实现完整的排序能力，通常也需要实现__le__、__ge__和__eq__。Python的functools.total_ordering装饰器可以帮助我们通过只实现__eq__和__lt__（或__le__、__gt__、__ge__中的任意一个），自动补齐其他比较方法。
- 静态检查工具: Protocol主要用于静态类型检查工具（如MyPy、Pylance），在运行时Python本身并不会强制检查对象是否符合某个Protocol。
- 泛型与TypeVar: 结合TypeVar使用Protocol，可以让我们编写出既能享受Protocol带来的结构化类型检查，又能保持函数泛型特性的代码，使得类型提示更加精确和实用。
通过这种方式，我们不仅能够清晰地表达参数的类型要求（既可哈希又可排序），还能让静态类型检查工具在编译时就捕获潜在的类型不匹配错误，显著提升代码的健壮性和可维护性。
