질문의 역사. Python 3.7 이전에는 제네릭 타입을 구현하기 위해 복잡한 메타클래스 TypingMeta가 필요했으며, 이는 getitem을 가로채서 **List[int]**와 같은 서브스크립팅을 처리했습니다. 이 접근 방식은 느리고, typing 모듈 내에서 순환 종속성을 생성하며, 각 제네릭 작업이 무거운 메타클래스 로직을 탐색해야 하기 때문에 디버깅이 어려웠습니다. PEP 560은 이러한 성능 및 아키텍처 문제를 해결하기 위해 전용 프로토콜을 도입했습니다.
문제. 제네릭 클래스는 정적 타입 검사를 지원하고 실제 인스턴스를 생성하지 않고도 런타임 내에서 타입 검사를 수행할 수 있도록 클래스 수준에서 타입 인자(예: **List[int]**의 int)를 수용해야 합니다. 문제는 이러한 인자를 경량 객체에 저장하면서 제네릭 출처와 그 매개변수 간의 관계를 유지하고, 클래스를 init을 호출하지 않고도 반복적으로 서브스크립트할 수 있어야 하는 것이었습니다.
해결책. Python 3.7+는 Generic 기본 클래스에서 class_getitem 듀nder 메서드를 구현하며, 이 메서드는 클래스가 서브스크립트될 때 자동으로 호출됩니다(예: Container[int]). 이 메서드는 원래 클래스를 origin에 저장하고 타입 인자를 args에 저장하는 GenericAlias 객체(내부 타입은 _GenericAlias인 CPython)를 반환합니다. 이 메커니즘은 인스턴스화를 완전히 피하고 이러한 별칭 객체를 효율성을 위해 캐싱합니다.
from typing import Generic, TypeVar T = TypeVar('T') class Container(Generic[T]): def __init__(self, value: T) -> None: self.value = value # 런타임 서브스크립팅은 인스턴스가 아니라 GenericAlias를 생성합니다. SpecializedType = Container[int] print(SpecializedType) # <class '__main__.Container[int]'> print(SpecializedType.__origin__) # <class '__main__.Container'> print(SpecializedType.__args__) # (<class 'int'>,) # 인스턴스화는 별도로 발생합니다. instance = SpecializedType(42)
문제 설명. 데이터 검증 라이브러리는 사용자 제공 타입 힌트를 기반으로 중첩된 JSON 구조를 Python 객체로 파싱해야 했습니다. 핵심 과제는 런타임에서 제네릭 컨테이너 내에 포함된 타입을 결정하여 올바른 서브 객체를 재귀적으로 인스턴스화하는 것이었습니다. 이를 위해서는 모든 가능한 제네릭 조합을 하드코딩하지 않아야 했습니다.
해결책 1: 타입 표현의 문자열 파싱. 장점: str(type_hint) 및 정규식을 사용하여 신속하게 구현할 수 있습니다. 단점: 매우 취약하며 전방 참조, 타입 유니온 또는 중첩 제네릭에서 Break되고, 다른 모듈의 유사한 이름을 가진 타입을 구별하지 못합니다.
해결책 2: 사용자가 모든 제네릭 클래스를 장식해야 하는 수동 메타클래스 등록. 장점: 타입 매개변수 저장 및 검색에 대한 완전한 제어가 가능합니다. 단점: 라이브러리 사용자에게 큰 부담을 주고, 사용자의 클래스가 이미 사용자 정의 메타클래스를 사용하는 경우 메타클래스 충돌이 발생하며, 표준 라이브러리에 이미 존재하는 기능을 중복합니다.
해결책 3: get_origin() 및 **get_args()**를 통해 class_getitem 내성을 활용합니다. 장점: 표준 GenericAlias 프로토콜을 활용하며, 임의로 중첩된 구조를 견고하게 처리하고, 복잡한 상속 계층에 대한 MRO를 존중합니다. 추가적인 사용자 코드가 필요하지 않습니다. 단점: 기술적으로 구현 세부 사항인 origin과 같은 내부 속성을 이해해야 하며, 현대 Python 버전에서 안정화되었습니다.
선택된 솔루션. 해결책 3이 PEP 560 및 현대 Python 타입 시스템 아키텍처와 일치하기 때문에 선택되었습니다. **get_origin(type_hint)**로 기본 컨테이너(예: dict)를 찾아내고, **get_args(type_hint)**로 매개변수화된 타입(예: str, User)을 추출하여 라이브러리가 검증기를 재귀적으로 구성합니다. 이 접근 방식은 사용자가 정의한 제네릭이 **Generic[T]**에서 상속받을 때도 매개변수 목록을 변경하지 않고 원할하게 작동합니다.
결과. 이 라이브러리는 복잡한 중첩 페이로드를 타입 안전한 Python 객체로 성공적으로 역직렬화합니다. 사용자는 **class PaginatedResponse(Generic[T]): ...**를 정의할 수 있으며, 시스템은 **PaginatedResponse[OrderDetail]**를 만날 때마다 T를 자동으로 추출하여 올바른 제네릭 서브트리를 인스턴스화하면서 IDE 지원 및 런타임 검증을 위한 전체 타입 정보를 유지합니다.
왜 isinstance([1, 2, 3], List[int])는 TypeError를 발생시키며, 이 제한은 제네릭 타입 별칭과 구체적인 런타임 타입 간의 구별을 어떻게 반영합니까?
Python의 isinstance는 두 번째 인수가 타입, 타입 튜플 또는 instancecheck 메서드가 있는 객체여야 합니다. **List[int]**는 class_getitem에 의해 생성된 GenericAlias 객체이므로 클래스가 아닙니다. Python이 점진적 타입을 사용하기 때문에 제네릭 매개변수는 런타임에서 제거됩니다; 리스트 **[1,2,3]**는 **List[int]**와 **List[str]**로 매개변수화되었던 기억이 없습니다. isinstance가 GenericAlias에서 호출되면 TypeError: isinstance() arg 2 must be a type, tuple of types, or a union이 발생합니다. 호환성을 확인하려면 구조를 수동으로 검증하거나 메서드 존재만 확인하는 @runtime_checkable Protocol을 사용해야 합니다.
__class_getitem__은 다중 전문화 제네릭 부모를 상속하는 클래스에서 메서드 해석 순서와 어떻게 상호작용합니까? 예를 들어 class MyMapping(Dict[str, int], Mapping[str, Any])는 어떻게 됩니까?
Python이 MyMapping을 생성할 때 각 기본 클래스를 처리합니다. **Dict[str, int]**와 **Mapping[str, Any]**는 모두 각각의 원본에서 class_getitem 호출의 결과인 GenericAlias 객체입니다. MRO 계산은 이를 별개의 기본으로 취급하지만, Generic 메커니즘은 타입 인자 정보를 보존하기 위해 원래 구독된 기본을 orig_bases에 저장합니다. 이는 **get_type_hints(MyMapping)**가 MyMapping이 Dict 브랜치에서 str 및 int로 매개변수화되었음을 해결하고, Mapping 브랜치가 구조적 일관성을 제공하도록 합니다. 중요한 세부 사항은 class_getitem이 상속 중에 다시 호출되지 않는다는 것입니다. 대신 기존 별칭이 새 클래스에 첨부되고, 특정 추상 기본 클래스에 대해 mro_entries가 최종 MRO를 조정하여 제네릭 원본 클래스가 올바르게 표시되도록 할 수 있습니다.
제네릭 클래스 정의상의 __parameters__와 전문화된 GenericAlias에서의 args 간의 구별은 무엇이며, TypeVar로 제네릭을 서브스크립트할 때 __args__가 그 바운드가 아닌 TypeVar 객체 자체를 포함하는 이유는 무엇인가요?
parameters는 클래스 헤더에 선언된 공식 TypeVar 객체(예: T)를 포함하는 클래스 속성 튜플로, 제네릭의 추상 타입 슬롯을 나타냅니다. args는 class_getitem에 의해 생성된 GenericAlias 인스턴스에서 나타나며, 그러한 매개변수에 대해 대체된 구체적인 타입을 포함합니다(예: int). **Container[T]**를 생성할 때 T가 TypeVar인 경우(다른 제네릭 함수 내부에서 자주 발생), args는 TypeVar 인스턴스를 포함합니다. 구체적인 바인딩은 외부 스코프가 특정 타입을 제공할 때까지 지연되기 때문입니다. 이 메커니즘은 고차 제네릭 패턴을 지원하며, **Callable[[T], T]**와 같은 타입이 여러 수준의 제네릭 추상화 전반에 걸쳐 입력 및 출력 타입 간의 관계를 유지하게 합니다. TypeVar의 bound 속성은 최종 해상도가 **typing.get_type_hints()**를 통해 발생할 때만 사용됩니다.