Deskriptory zostały sformalizowane w Pythonie 2.2 razem z nowymi klasami stylu, aby zapewnić jednolity protokół dla kontroli dostępu do atrybutów. Przed tą innowacją, wbudowane typy, takie jak property i classmethod, polegały na kodzie specjalnym w interpreterze. Wprowadzenie protokołu deskriptorów pozwoliło klasom zdefiniowanym przez użytkownika na wykazywanie zachowań wcześniej zarezerwowanych dla wbudowanych. Konwencja przekazywania None dla parametru instancji powstała organicznie z potrzeby rozróżnienia między dostępem na poziomie klasy a dostępem na poziomie instancji, bez fragmentowania protokołu na wiele metod.
Bez mechanizmu do wykrywania, kiedy dostęp następuje do samej klasy, deskriptory byłyby zmuszone do bezwarunkowego zwracania siebie, co uniemożliwiłoby implementację właściwości na poziomie klasy lub introspekcję schematu. Alternatywnie, protokół wymagałby oddzielnych metod pomocniczych dla dostępu do klasy i instancji, co znacznie skomplikowałoby model obiektowy. Wyzwaniem było zaprojektowanie jednej sygnatury metody zdolnej do eleganckiego obsługiwania obu wzorców dostępu, przy jednoczesnym zachowaniu zgodności wstecznej i minimalnych kosztów wydajności.
Sygnatura metody __get__(self, instance, owner) otrzymuje None dla parametru instance podczas dostępu jako Class.attribute, a rzeczywisty obiekt instancji podczas dostępu jako instance.attribute. Parametr owner zawsze otrzymuje klasę definicyjną. To pozwala deskriptorom na implementację logiki warunkowej: zwracanie metadanych lub samego deskriptoru, gdy instance is None, lub zwracanie obliczonych wartości, gdy instancja istnieje. Ta konwencja umożliwia implementację classmethod i staticmethod w czystym Pythonie i wspiera zaawansowane wzorce, takie jak schematy walidacji na poziomie klasy.
Zespół inżynierii danych potrzebował deklaratywnej ramy walidacyjnej, w której definicje pól dostarczałyby metadane podczas inspekcji na poziomie klasy do automatycznego generowania dokumentacji OpenAPI, ale przeprowadzały walidację danych, gdy były używane na instancjach. Początkowa implementacja z użyciem naiwnych deskriptorów zawiodła, ponieważ dostęp do User.email w klasie zwracał surowy obiekt deskriptoru, nie oferując żadnych informacji o typie ani ograniczeniach.
Jednym z rozważanych podejść było implementowanie oddzielnych metod klasowych do pobierania metadanych. To wiązało się z tworzeniem metody get_schema(), która ręcznie przeglądała słownik klasy, aby wyciągnąć informacje o polach. Choć było to proste i łatwe do zrozumienia dla młodszych programistów, stworzyło niebezpieczny rozdział między definicjami pól a ich możliwościami introspekcji. Zalety: Przejrzysta implementacja wymagająca żadnej zaawansowanej wiedzy z zakresu Pythona. Wady: Naruszała zasadę DRY, wymagała utrzymania równoległych struktur logiki oraz okazała się zawodna, gdy definicje pól ewoluowały.
Drugie podejście wykorzystało konwencję None protokołu deskriptorów, sprawdzając if instance is None w środku __get__. Gdy ten warunek był prawdziwy, deskriptor zwracał obiekt FieldSchema zawierający ograniczenia typów i walidatory; w przeciwnym razie, przeprowadzał walidację i zwracał rzeczywistą wartość. Zalety: Ujednolicona API pod jedną nazwą atrybutu, podążała za konwencjami Pythonic i zapewniała automatyczne wsparcie dla dziedziczenia. Wady: Wymagała głębokiego zrozumienia mechanizmu wyszukiwania atrybutów w CPythonie i okazała się trudniejsza do debugowania dla programistów nieobeznanych z wewnętrznymi aspektami deskriptorów.
Trzecią opcją było użycie metaklasy, aby przechwycić tworzenie klas i wstrzyknąć syntetyczne właściwości do dostępu do schematów. Choć oferowało to pełną kontrolę nad zachowaniem klasy, wprowadziło znaczny poziom złożoności do hierarchii klas i skomplikowało proces debugowania. Zalety: Całkowita kontrola nad zachowaniem. Wady: Przesadnie skomplikowana dla wymagań, wpływała na obliczenia kolejności rozwiązywania metod i znacząco zwiększała czas importu.
Zespół wybrał drugie rozwiązanie, ponieważ wykorzystywało istniejące mechanizmy CPython bez wprowadzania dodatkowych warstw abstrakcji. Sprawdzanie None dostarczało wystarczającego kontekstu, aby odróżnić wzorce dostępu w czasie dokumentacji i w czasie rzeczywistym, zmniejszając bazę kodu o czterdzieści procent w porównaniu do podejścia z metodą explicit.
Ostateczna rama pozwoliła, aby User.email zwracał kompleksowy obiekt schematu, podczas gdy user.email zwracał zweryfikowaną wartość ciągu. To podwójne zachowanie umożliwiło automatyczne generowanie specyfikacji OpenAPI poprzez prostą inspekcję klasy, zmniejszając utrzymanie dokumentacji o dziewięćdziesiąt procent i eliminując całą kategorię błędów synchronizacji między implementacją a dokumentacją.
Jak różnią się deskriptory danych (implementujące zarówno __get__, jak i __set__) od deskriptorów bez danych w kolejności wyszukiwania atrybutów i dlaczego ta różnica zapobiega maskowaniu atrybutów klasy przez słowniki instancji w niektórych przypadkach, a w innych nie?
Deskriptory danych implementują zarówno __get__, jak i __set__, podczas gdy deskriptory bez danych implementują tylko __get__. W mechanizmie rozwiązywania atrybutów w Pythonie, deskriptory danych mają pierwszeństwo przed __dict__ instancji. Oznacza to, że przypisanie do instance.attr zawsze wywoła metodę __set__ deskriptora, nawet jeśli instancja wcześniej miała ten klucz w swoim słowniku. Z drugiej strony, deskriptory bez danych pozwalają na maskowanie ich przez słownik instancji; jeśli przypiszesz instance.attr = value, instancja zyskuje nowy wpis w __dict__, a kolejne dostępy pobierają tę wartość zamiast wywoływać deskriptor. Ta różnica jest kluczowa dla implementacji właściwości buforowanych (bez danych) w porównaniu z atrybutami tylko do odczytu (dane). Kandydaci często nie dostrzegają, że samo zdefiniowanie __set__ zmienia semantykę wyszukiwania, nawet jeśli metoda po prostu zgłasza AttributeError, co jest dokładnie tym, jak obiekty property wymuszają niemutowalność.
Dlaczego niestandardowe deskriptory muszą implementować __set_name__ zamiast zapisywać nazwę atrybutu w __init__, szczególnie gdy ta sama instancja deskriptora jest przypisywana do wielu atrybutów klasy lub używana z dziedziczeniem?
Gdy jedna instancja deskriptora jest przypisywana do wielu nazw (np. x = y = MyDescriptor()), przechowywanie nazwy w __init__ powoduje, że druga przypisanie nadpisuje pierwsze, prowadząc do niepoprawnego rozwiązywania nazw. Ponadto, podczas dziedziczenia klas, deskriptory klas rodzicielskich nie są ponownie inicjowane dla klas podrzędnych. Metoda __set_name__, wprowadzona w Pythonie 3.6, jest wywoływana przez interpreter dokładnie raz podczas tworzenia klasy, otrzymując zarówno klasę właściciela, jak i nazwę atrybutu. To zapewnia poprawne powiązanie, nawet przy złożonej dziedziczeniu lub wielu przypisaniach. Bez tej metody, deskriptory nie mogą generować dokładnych komunikatów o błędach ani przeprowadzać introspekcji wymagającej ich nazwy atrybutu, co prowadzi do cichych awarii podczas operacji metaprogramowania.
Jak protokół deskriptorów współdziała z __slots__, i jaki konkretny tryb awarii występuje, gdy niestandardowy deskriptor w klasie z __slots__ dzieli swoją nazwę z slotem?
Mechanizm Python's __slots__ wewnętrznie implementuje deskriptory danych, aby zarządzać przechowywaniem atrybutów w tablicach o stałym rozmiarze zamiast słownikach. Gdy definiujesz __slots__ = ['name'], CPython tworzy deskriptor dla name w słowniku klasy. Jeśli następnie zdefiniujesz niestandardowy deskriptor z def name(self): ..., nadpisujesz deskriptor slotu, całkowicie łamiąc mechanizm slotów. To powoduje AttributeError, ponieważ niestandardowy deskriptor nie ma poziomów protokołów slotów na poziomie C, które są niezbędne do uzyskania dostępu do przechowywania slotów. Kandydaci często nie dostrzegają, że deskriptory slotów to deskriptory danych z wyspecjalizowanymi implementacjami C. Rozwiązaniem jest albo użycie innej nazwy atrybutu dla niestandardowego deskriptoru, albo staranne delegowanie do metod __get__ i __set__ oryginalnego deskriptora slotu, chociaż to wymaga rygorystycznej obsługi, aby zapobiec nieskończonej rekurencji.