为何Python泛型采用__class_getitem__而非元类的__getitem__实现？

这是个直击Python泛型设计本质的问题，__class_getitem__的引入绝非重复造轮子，而是为了解决元类方案在实际场景中的多个核心痛点：

1. 避免元类的侵入性与复杂度 #

元类是Python中相对进阶的特性，用元类实现泛型会强制类依赖自定义元类，带来两个棘手问题：

• 元类冲突：如果一个类已经需要继承其他元类（比如dataclass的内部元类、Enum的EnumMeta），叠加泛型元类会触发多重元类继承的冲突——Python不支持非直系继承的元类叠加，直接限制了类的功能组合。
• 学习与维护成本：理解元类的运作机制需要额外的学习成本，而__class_getitem__作为普通类方法，代码意图更直观，新手也能快速上手实现简单泛型。

比如给一个dataclass添加泛型支持，用__class_getitem__只需几行代码：

from dataclasses import dataclass

@dataclass
class Box:
    content: object

    def __class_getitem__(cls, item_type):
        # 简化实现，实际可返回标准GenericAlias
        return f"Box[{item_type}]"

print(Box[str])  # 输出 Box[<class 'str'>]

如果用元类方案，你需要自定义一个同时继承type和dataclasses._DataclassMeta的元类，不仅复杂，还可能因为内部元类的版本变化导致兼容性问题。

2. 语义更精准，代码意图更清晰 #

元类的__getitem__本质是元类对类对象的操作，而__class_getitem__是类自身处理类对象的下标请求，后者的语义更贴合“类对象下标操作”的场景：

• 元类方案中，MyGeneric[int]的逻辑是「调用元类的__getitem__，传入MyGeneric这个类对象和int」
• __class_getitem__方案中，MyGeneric[int]的逻辑是「调用MyGeneric类自身的__class_getitem__，传入int」

后者的代码意图更直接，不需要理解元类与类的层级关系就能看懂。

3. 兼容现有代码的行为 #

在__class_getitem__引入前，已有不少类用元类的__getitem__实现了其他功能，最典型的就是Enum——它的元类EnumMeta的__getitem__用来按名称获取枚举成员（比如Color['RED']）。

如果泛型依赖元类的__getitem__，会直接与这些现有功能冲突。而Python设计时规定：元类的__getitem__优先级高于__class_getitem__，这既保留了现有代码的行为，又能让新类通过__class_getitem__实现泛型，完美解决了兼容性问题。

4. 降低泛型的实现门槛 #

对于只需要简单泛型标记的场景，__class_getitem__提供了轻量化的实现方式，不需要定义复杂的元类结构。比如你可以快速实现一个仅用于类型标注的泛型类：

class MyCollection:
    def __class_getitem__(cls, item_type):
        from typing import GenericAlias
        return GenericAlias(cls, item_type)

# 用于类型标注
def process(items: MyCollection[str]) -> None:
    pass

这种实现方式简洁高效，完全不需要涉及元类的复杂逻辑。

5. 符合PEP的设计目标 #

__class_getitem__是PEP 560（Runtime Generics）的核心内容之一，该PEP的目标就是让Python的泛型系统更易用、更灵活，减少对元类的依赖，让普通类也能轻松支持泛型下标操作。通过引入这个特殊方法，Python实现了「泛型无需绑定元类」的设计初衷。

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