在 Pycharm 中,以下代码会产生警告:
from typing import List
list1: List[int] = [1, 2, 3]
list2: List[str] = ["1", "2", "3"]
list3: List[object] = list1 + list2
# ↳ Expected type List[int] (matched generic type List[_T]),
# got List[str] instead.
为什么?我不应该连接两个混合的、暗示类型的列表吗?
根据评论中的要求,以下是类型检查器不允许这样做的一些原因。
list.__add__
的类型签名根本不允许传入包含相同类型的列表以外的任何内容:
_T = TypeVar('_T')
# ...snip...
class list(MutableSequence[_T], Generic[_T]):
# ...snip...
def __add__(self, x: List[_T]) -> List[_T]: ...
支持 PEP 484 的 Pycharm 使用(部分)来自 Typeshed 的数据。
我们有可能以某种方式扩展这种类型签名(例如,重载它以接受
List[_S]
并在这种情况下返回 List[Union[_T, _S]]
),但我认为没有人愿意研究这种方法的可行性:这种事情在实践中并不太有用,对于那些想要严格同类列表或想要子类化它们的人来说,生活变得更加困难,并且可能会破坏依赖于当前类型签名的“很多”现有代码。
这种类型签名也可能反映了 PEP 484 初始设计期间做出的更广泛的选择,即假设列表始终是同质的——始终包含相同类型的值。
严格来说,PEP 484 的设计者不需要做出这样的选择:他们可能需要类型检查器来与它进行特殊情况的交互,就像我们目前对元组所做的那样。但我认为,总体而言,不这样做会更简单。 (也可以说是更好的风格,但无论如何。)
第二个原因与 PEP 484 类型系统的基本限制有关:无法声明某些函数或方法不会修改状态。
lst1.__add__(lst2)
lst1
是一些奇怪的列表子类,它将项目从
lst2
复制到自身呢?然后暂时将
lst1
的类型从
SomeListSubtype[int]
放宽到
SomeListSubtype[object]
是不安全的:在从
lst1
添加/注入字符串后,
lst2
将不再仅包含整数。
当然,实际上编写这样的子类也是不好的做法,但是类型检查器无法假设用户在不强制执行的情况下会遵循最佳实践:类型检查器、编译器和类似的工具从根本上来说都是保守的野兽。
最后,值得注意的是,这些问题本质上都不是不可克服的。类型检查器实现者可以做几件事,例如:
修改列表的类型签名(并确保它不会破坏任何现有代码)
其他评论中明确解释了原因,因此我只想为那些无法跳过代码中的串联步骤并且不想看到这个烦人的警告的人强调潜在的解决方法。
list1 += list2
有时我不得不这样做:
[*list1, *list2]
就像 Pycharm 所说,这只是一个警告,您可以连接不同的对象或列表,但这被认为是一种不好的做法。