Historia pytania. Przed Python 3.7, implementacja typów ogólnych wymagała skomplikowanej metaklasy TypingMeta, która przechwytywała getitem, aby obsługiwać subscripting, jak List[int]. Podejście to było wolne, tworzyło cykliczne zależności w samej bibliotece typing i utrudniało debugowanie, ponieważ każda operacja generyczna przechodziła przez ciężką logikę metaklasy. PEP 560 wprowadził dedykowany protokół, aby rozwiązać te problemy z wydajnością i architekturą.
Problem. Typy ogólne muszą akceptować argumenty typowe (jak int w List[int]) na poziomie klasy, a nie instancji, aby wspierać statyczne sprawdzanie typów i introspekcję w czasie działania bez tworzenia faktycznych instancji. Wyzwanie polegało na przechowywaniu tych argumentów w lekkim obiekcie, który zachowuje relację między ogólnym źródłem a jego parametrami, jednocześnie pozwalając na wielokrotne subskrybowanie klas bez wywoływania init.
Rozwiązanie. Python 3.7+ implementuje metodę dunder class_getitem w bazowej klasie Generic, która jest automatycznie wywoływana, gdy klasa jest subskrybowana (np. Container[int]). Metoda ta zwraca obiekt GenericAlias (wewnętrzny typ _GenericAlias w CPython), który przechowuje oryginalną klasę w origin oraz argumenty typowe w args. Mechanizm ten całkowicie unika instancjonowania i buforuje te obiekty aliasów dla efektywności.
from typing import Generic, TypeVar T = TypeVar('T') class Container(Generic[T]): def __init__(self, value: T) -> None: self.value = value # Runtime subscripting tworzy GenericAlias, a nie instancję SpecializedType = Container[int] print(SpecializedType) # <class '__main__.Container[int]'> print(SpecializedType.__origin__) # <class '__main__.Container'> print(SpecializedType.__args__) # (<class 'int'>,) # Instancjonowanie odbywa się osobno instance = SpecializedType(42)
Opis problemu. Biblioteka do walidacji danych potrzebowała przetwarzać zagnieżdżone struktury JSON na obiekty Python w oparciu o podane przez użytkownika wskazówki typowe jak Dict[str, List[User]] lub Optional[Tuple[int, str]]. Kluczowym wyzwaniem było określenie, w czasie działania, jakie typy były zawarte w ogólnych kontenerach, aby rekurencyjnie zainicjować odpowiednie sub-obiekty, bez kodowania na sztywno każdej możliwej kombinacji typów ogólnych.
Rozwiązanie 1: Parsowanie łańcuchów reprezentacji typów. Zalety: Szybkie do zaimplementowania przy użyciu str(type_hint) i regex. Wady: Niezwykle kruche, łamie się na referencjach w przód, uniach typów lub zagnieżdżonych ogólnych, i nie rozróżnia typów o podobnych nazwach w różnych modułach.
Rozwiązanie 2: Ręczna rejestracja metaklas wymagająca, aby użytkownicy dekorowali każdą ogólną klasę. Zalety: Pełna kontrola nad przechowywaniem i pobieraniem parametrów typowych. Wady: Nakłada duże obciążenie na użytkowników biblioteki, tworzy konflikty metaklas, gdy ich klasy już używają własnych metaklas, i duplikuje funkcjonalność już obecną w standardowej bibliotece.
Rozwiązanie 3: Wykorzystanie introspekcji class_getitem za pomocą get_origin() i get_args(). Zalety: Wykorzystuje standardowy protokół GenericAlias, skutecznie obsługuje dowolnie zagnieżdżone struktury i respektuje MRO dla złożonych hierarchii dziedziczenia bez dodatkowego kodu od użytkownika. Wady: Wymaga zrozumienia wewnętrznych atrybutów jak origin, które są technicznie szczegółami implementacyjnymi, chociaż ustabilizowanymi w nowoczesnych wersjach Python.
Wybrane rozwiązanie. Rozwiązanie 3 zostało wybrane, ponieważ jest zgodne z PEP 560 i nowoczesną architekturą systemu typów Python. Sprawdzając get_origin(type_hint), aby znaleźć bazowy kontener (np. dict) i get_args(type_hint), aby wyodrębnić typy parametryzowane (np. str, User), biblioteka rekurencyjnie konstruuje walidatory. To podejście działa płynnie z użytkownikami definiowanymi typami ogólnymi dziedziczącymi z Generic[T] bez konieczności modyfikacji ich definicji klas.
Rezultat. Biblioteka skutecznie deserializuje złożone zagnieżdżone ładunki na typowo bezpieczne obiekty Python. Użytkownicy mogą zdefiniować class PaginatedResponse(Generic[T]): ..., a system automatycznie wyodrębnia T, gdy napotyka na PaginatedResponse[OrderDetail], instancjonując poprawny ogólny poddrzewo, zachowując pełne informacje o typach dla wsparcia IDE i walidacji w czasie działania.
Dlaczego isinstance([1, 2, 3], List[int]) podnosi TypeError, i jak to ograniczenie odzwierciedla różnicę między ogólnymi aliasami typów a konkretnymi typami w czasie działania?
Python's isinstance wymaga, aby jego drugi argument był typem, krotką typów lub obiektem z metodą instancecheck. List[int] jest obiektem GenericAlias utworzonym przez class_getitem, a nie klasą. Ponieważ Python używa typowania stopniowego, parametry ogólne są usuwane w czasie wykonywania; lista [1,2,3] nie ma pamięci o tym, że była parametryzowana jako List[int] w porównaniu z List[str]. Próbując isinstance na GenericAlias podnosi TypeError: isinstance() arg 2 must be a type, tuple of types, or a union. Aby sprawdzić zgodność, należy ręcznie zweryfikować strukturę lub użyć @runtime_checkable Protocols, które tylko sprawdzają obecność metod, a nie parametry ogólne.
Jak class_getitem współdziała z Kolejnością Rozwiązywania Metod, gdy klasa dziedziczy po wielu wyspecjalizowanych rodzicach ogólnych, jak klasa MyMapping(Dict[str, int], Mapping[str, Any])?
Gdy Python tworzy MyMapping, przetwarza każdą klasę bazową. Dict[str, int] i Mapping[str, Any] są obiektami GenericAlias powstałymi w wyniku wywołań class_getitem na ich odpowiednich pochodnych. Obliczenie MRO traktuje je jako odrębne bazy, ale mechanizm Generic przechowuje oryginalne subskrybowane bazy w orig_bases, aby zachować informacje o argumentach typowych. To pozwala get_type_hints(MyMapping) rozwiązać, że MyMapping jest parametryzowany nad str i int z gałęzi Dict, podczas gdy gałąź Mapping zapewnia zgodność strukturalną. Kluczowym szczegółem jest to, że class_getitem nie jest ponownie wywoływane podczas dziedziczenia; zamiast tego istniejące aliasy są dołączane do nowej klasy, a mro_entries (dla niektórych abstrakcyjnych klas bazowych) mogą dostosować ostateczne MRO, aby odpowiednie klasy źródłowe pojawiały się prawidłowo.
Jaka jest różnica między parameters w definicji ogólnej klasy a args w wyspecjalizowanym GenericAlias, i dlaczego subscripting ogólnego z TypeVar skutkuje tym, że args zawiera sam obiekt TypeVar, a nie jego wiązanie?
parameters jest krotką atrybutu klasy zawierającą formalne obiekty TypeVar (np. T) zadeklarowane w nagłówku klasy, reprezentujące abstrakcyjne sloty typu ogólnego. args pojawia się w instancji GenericAlias utworzonej przez class_getitem i zawiera konkretne typy zastąpione przez te parametry (np. int). Gdy tworzysz Container[T], gdzie T jest TypeVar (często wewnątrz innej funkcji ogólnej), args zawiera instancję TypeVar, ponieważ konkretne wiązanie jest opóźnione, aż zewnętrzny zasięg dostarczy konkretnego typu. Ten mechanizm wspiera wzorce ogólne wyższego rzędu, pozwalając typom takim jak Callable[[T], T] zachować relację między typami wejściowymi i wyjściowymi przez wiele poziomów ogólnej abstrakcji, używając właściwości bound obiektu TypeVar tylko wtedy, gdy finalne rozwiązanie następuje za pomocą typing.get_type_hints().