基于Basedpyright项目的Mapping类型参数协变性探讨

在Python类型系统中，Mapping类型的第一个类型参数是否应该支持协变是一个值得深入讨论的话题。本文将从技术角度分析这一设计决策的利弊，并探讨可能的解决方案。

协变性的基本概念

在类型系统中，协变性(covariance)指的是子类型关系能够随着类型参数一起保持的特性。具体到Mapping类型，如果K1是K2的子类型，那么Mapping[K1, V]能否被视为Mapping[K2, V]的子类型。

当前Mapping的设计

Python标准库中的Mapping类型将键类型参数设计为不变(invariant)的。这意味着即使str是object的子类型，Mapping[str, object]也不能被视为Mapping[object, object]的子类型。

这种设计的主要原因是考虑到潜在的类型安全问题。如果允许键类型协变，某些特殊实现的Mapping子类可能会违反类型安全。

协变设计的潜在风险

一个典型的危险示例是当Mapping子类内部存储了键值，并通过其他方法暴露这些键时。如果允许协变，可能会导致类型系统无法捕获的运行时错误：

class UnsafeMapping(Mapping[K, V]):
    _stored_key: K
    
    def __getitem__(self, key: K) -> V:
        self._stored_key = key  # 存储键值
        return self.value
    
    def get_key(self) -> K:
        return self._stored_key

如果允许协变，以下代码将通过类型检查但在运行时出错：

m: Mapping[str, object] = UnsafeMapping("key", "value")
b: Mapping[object, object] = m  # 假设允许协变
b[2]  # 传入int类型的键
m.get_key()  # 返回的应该是str，实际是int

替代解决方案

考虑到标准Mapping类型保持不变的合理性，我们可以通过以下方式实现协变需求：

1. 使用Protocol定义协变Mapping接口：

from typing import Protocol, TypeVar, Collection
from collections.abc import ItemsView, KeysView, ValuesView

_KT_co = TypeVar("_KT_co", covariant=True)
_VT_co = TypeVar("_VT_co", covariant=True)

class CoMapping(Collection[_KT_co], Protocol, Generic[_KT_co, _VT_co]):
    """协变版本的Mapping接口"""
    def items(self) -> ItemsView[_KT_co, _VT_co]: ...
    def keys(self) -> KeysView[_KT_co]: ...
    def values(self) -> ValuesView[_VT_co]: ...
    def __contains__(self, key: object, /) -> bool: ...
    def __eq__(self, other: object, /) -> bool: ...

2. 在需要协变的地方使用这个Protocol：

def process_mapping(m: CoMapping[str, object]) -> None:
    pass

m = {"key": "value"}
process_mapping(m)  # 正常工作

结论

虽然Mapping键类型的协变性在某些场景下看起来很有吸引力，但保持其不变性能够更好地保证类型安全。通过定义专门的协变Protocol，我们可以在需要协变的场景中获得灵活性，同时不影响标准Mapping类型的安全性。这种折中方案既满足了大多数使用场景的需求，又避免了潜在的类型安全问题。