Historia pytania
Zanim Python 2.5 wprowadził konstrukcję with za pośrednictwem PEP 343, zarządzanie zasobami wymagało stosowania jawnych bloków try/finally w rozproszonych kodach. Chociaż działało, ten wzorzec był obszerny i podatny na błędy w prostych scenariuszach związanych z pozyskiwaniem i zwalnianiem zasobów. Moduł contextlib został wprowadzony, aby zredukować ten szum biurokratyczny, pozwalając programistom pisać menedżerów kontekstu jako funkcje generatorów, wykorzystując dekorator @contextmanager do przekształcania generatorów o sekwencyjnym wyglądzie w obiekty spełniające protokół zarządzania kontekstem.
Problem
Funkcja generatora natywnie implementuje protokół iteratora (__iter__, __next__), a nie protokół menedżera kontekstu (__enter__, __exit__). Fundamentalne wyzwanie polega na złączeniu tych odmiennych protokołów: podczas wchodzenia w blok with, kod przygotowujący przed yield musi zostać wykonany; przy wychodzeniu, kod sprzątający po yield musi zostać uruchomiony niezależnie od wyjątków. Ponadto wyjątki zgłoszone wewnątrz bloku with muszą być wstrzykiwane z powrotem do generatora w dokładnym punkcie zawieszenia yield, co pozwala na uruchomienie logiki obsługi wyjątków samego generatora, aby wykonać operacje sprzątające.
Rozwiązanie
Dekorator owijająca funkcję generatora w klasę GeneratorContextManager (zaimplementowaną w C w nowoczesnym CPython). Każde wywołanie tworzy nowy iterator generatora. Metoda __enter__ wywołuje next() na tym iteratorze, wykonując funkcję aż do instrukcji yield, a następnie zwraca wartość zwróconą, aby przypisać ją do zmiennej as. Metoda __exit__ otrzymuje szczegóły wyjątku; jeśli nie wystąpił żaden wyjątek, wykonuje ponownie next(), aby wznowić i wyczerpać generator. Jeśli wystąpił wyjątek, wywołuje metodę throw() generatora, wstrzykując wyjątek w zawieszonym punkcie yield. Pozwala to na wykonanie bloków except lub finally generatora, aby obsługiwały sprzątanie. Jeśli throw() normalnie zwraca (wyjątek złapany), __exit__ zwraca True, aby stłumić wyjątek; w przeciwnym razie propaguje go dalej.
from contextlib import contextmanager @contextmanager def managed_connection(): conn = create_connection() try: print("Połączenie nawiązane") yield conn except NetworkError: conn.rollback() raise finally: conn.close() print("Połączenie zamknięte") with managed_connection() as c: c.query("SELECT * FROM data")
Opis problemu: Usługa przetwarzania danych o wysokiej wydajności musiała obsługiwać tymczasowe pliki przelewowe, gdy bufor w pamięci przekraczał limity. Dziedziczona implementacja powielała logikę tworzenia i usuwania plików w 12 różnych modułach przetwarzania, co prowadziło do wycieków deskryptorów plików w warunkach błędów brzegowych i komplikowało konserwację.
Rozważane rozwiązania:
Ręczne bloki try/finally były początkowym podejściem. Każde miejsce użycia owijało operacje plikowe w jawne try/finally, aby zapewnić wywołanie os.unlink(). Oferowało to wyraźny tok kontrolny bez dodatkowych kosztów abstrakcji, ale okazało się zbyt obszerne przy ośmiu linijkach na miejsce użycia i bardzo podatne na błędy. Programiści czasami umieszczali logikę sprzątania w niewłaściwym bloku finally, a modyfikowanie zachowania w sposób spójny we wszystkich modułach było żmudne, gdy dodawano wymagania dotyczące logowania.
Rozważono menedżera kontekstu opartego na klasie jako alternatywę do ponownego użycia. Klasa TempSpillFile zaimplementowałaby __enter__ w celu utworzenia pliku i __exit__ w celu jego usunięcia. Choć nadająca się do ponownego użycia i przestrzegająca standardowego protokołu, definicja klasy wizualnie oddzielałaby konfigurację od sprzątania na wielu linijkach, co psuło czytelność. Wymagałoby to również piętnastu linijek biurokracji w przypadku, który był koncepcyjnie prostym cyklem życia zasobów, zaciemniając rzeczywistą logikę.
Podejście z generatorem i @contextmanager było ostateczną opcją. Funkcja generatora temp_spill_file() utworzyłaby plik, zwróciłaby go, a następnie użyłaby try/finally do usunięcia. To zminimalizowało duplikację kodu i trzymało konfigurację oraz sprzątanie blisko siebie w kodzie źródłowym, korzystając z familiarnej składni obsługi wyjątków. Jednak narzuciło to ograniczenie do jednorazowego użycia, a punkt zawieszenia yield mógł zmylić programistów oczekujących synchronicznego działania.
Wybrane rozwiązanie i wynik: Wybrano podejście @contextmanager, ponieważ zminimalizowało duplikację kodu przy maksymalizacji klarowności podczas przeglądów kodu. Sąsiedztwo logiki pozyskiwania i zwalniania czyniło cykl życia zasobów natychmiast oczywistym. Refaktoryzacja zredukowała kod zarządzania zasobami z dziewięćdziesięciu sześciu linii do dwunastu linii w całym kodzie. Analiza statyczna potwierdziła brak wycieków deskryptorów plików w trakcie następnego kwartału użytkowania produkcyjnego.
Jak GeneratorContextManager obsługuje wyjątki, które występują w fazie konfiguracji (przed yield), a jak w fazie sprzątania (po yield)?
Jeśli wyjątek wystąpi przed yield w generatorze, generator nigdy nie wstrzymuje; __enter__ od razu propaguje ten wyjątek, a __exit__ nigdy nie jest wywoływane. Jeśli wyjątek wystąpi w bloku with (po yield), generator jest wstrzymywany. Następnie __exit__ wywołuje generator.throw(exc_type, exc_val, exc_tb), co wznawia generator w linii yield z aktywnym wyjątkiem. To pozwala na wykonanie własnych bloków except lub finally generatora. Kandydaci często pomijają, że throw() w rzeczywistości wznawia wykonywanie i że wyjątek uznawany jest za występujący w wyrażeniu yield z perspektywy generatora.
Dlaczego generator z dekoratorem contextmanager wymusza pojedynczy punkt yield, a jaki konkretny błąd występuje, jeśli ten warunek nie jest spełniony?
Protokół menedżera kontekstu zakłada pojedyncze wejście i wyjście. Jeśli generator próbuje zwrócić po raz drugi — albo dlatego, że __exit__ wywołuje next() (bez wyjątku) i generator ponownie zwraca zamiast powrócić, albo ponieważ wywołuje throw() i generator obsługuje wyjątek, a następnie zwraca ponownie — GeneratorContextManager podnosi RuntimeError z komunikatem „generator nie zatrzymał się”. Dzieje się tak, ponieważ maszyna stanów oczekuje, że generator zostanie wyczerpany po sprzątaniu. Kandydaci często mylą to ze standardową iteracją, gdzie wiele zwrotów jest ważnych, nie zdając sobie sprawy, że yield działa jako granica zawieszenia/wznawiania dla kontekstu, a nie jako sekwencja produkcji wartości.
W jakich okolicznościach metoda __exit__ klasy GeneratorContextManager tłumi wyjątek zgłoszony w bloku with, a jak to współdziała z obsługą wyjątków przez generator?
__exit__ tłumi wyjątek (zwraca True) tylko wtedy, gdy wstrzyknięty wyjątek przez throw() zostanie złapany w generatorze i generator osiągnie swój koniec (zgłasza StopIteration) bez ponownego zgłaszania wyjątku lub podnoszenia nowego. Jeśli generator złapie wyjątek i pozwoli, aby wywołanie throw() zakończyło się normalnie, __exit__ interpretuje to jako pomyślną obsługę i zwraca True. Jeśli generator nie złapie wyjątku, throw() propaguje go na zewnątrz, a __exit__ zwraca None (fałszywe), pozwalając na dalsze propagowanie wyjątku. Kandydaci często pomijają, że samo posiadanie try/except wewnątrz generatora nie wystarczy; wyjątek musi być złapany konkretnie z wywołania throw() i nie może być ponownie zgłaszany oraz że wymaga się jawnego return lub dojścia do końca po złapaniu dla stłumienia.