Protokół asynchronicznego menedżera kontekstu w Pythonie opiera się na dwóch konkretnych metodach dunder: __aenter__ i __aexit__. W przeciwieństwie do ich synchronicznych odpowiedników, obie muszą być zdefiniowane za pomocą async def, aby zwracały obiekty coroutine, które można oczekiwać. Gdy wchodzimy do bloku async with, interpreter oczekuje na __aenter__, przypisując jego wynik do zmiennej as; po wyjściu można oczekiwać na __aexit__ z detalami wyjątku, tłumiąc wyjątek tylko wtedy, gdy czekany wynik jest prawdziwy.
Nasza drużyna zajmująca się inżynierią danych potrzebowała wdrożyć menedżera połączeń dla asynchronicznego producenta Kafka, który automatycznie zarządzał transakcyjnymi partiami wiadomości. Wyzwanie polegało na zapewnieniu, że commit() lub abort() były wykonywane asynchronicznie w zależności od tego, czy wystąpił wyjątek podczas przetwarzania partii, bez wycieku połączeń w trakcie strumieniowania o dużej przepustowości.
Jednym z podejść było ręczne zarządzanie zasobami z użyciem jawnych bloków try/finally wokół każdej operacji partii. To zapewniało przejrzystą kontrolę, ale prowadziło do głęboko zagnieżdżonego, podatnego na błędy kodu, w którym deweloperzy często zapominali czekać na coroutine czyszczące w ścieżkach wyjątków, co powodowało wyczerpanie zasobów i niespójną stan.
Inną opcją było użycie dekoratora @contextlib.asynccontextmanager, aby owinąć asynchroniczny generator zwracający producenta. Choć to zredukowało nadmiar i poprawiło czytelność, wprowadziło narzut generatora i utrudniło implementację logiki warunkowego zatwierdzania, która badaklałaby typ wyjątku przed podjęciem decyzji, czy go stłumić dla błędów możliwych do ponownego przetworzenia.
Ostatecznie zdecydowaliśmy się na wdrożenie dedykowanej klasy AsyncKafkaTransaction z explicytnymi metodami __aenter__ i __aexit__. To rozwiązanie zapewniło optymalną wydajność i pozwoliło na precyzyjną kontrolę: __aenter__ czekał na rozpoczęcie transakcji, podczas gdy __aexit__ sprawdzał, czy wyjątek był KafkaTimeoutError, aby wywołać ponowną próbę (zwracając True) lub śmiertelny błąd do propagacji (zwracając False), zawsze czekając na odpowiednie czyszczenie bez względu na wszystko.
Wynikiem było potężne strumieniowanie, które obsługiwało miliony zdarzeń dziennie bez wycieków połączeń i łagodnego degradacji podczas podziałów sieciowych, wszystko przy użyciu czystej składni async with transaction as txn:.
Dlaczego __aenter__ musi być zdefiniowane za pomocą async def, nawet jeśli nie wykonuje żadnego wewnętrznego oczekiwania?
Interpreter Pythona bezwarunkowo czeka na obiekt zwrócony przez __aenter__ podczas przetwarzania instrukcji async with. Jeśli zdefiniowane jako zwykła metoda, zwraca bezpośrednio instancję, ale interpreter zgłosi TypeError, ponieważ wynik nie jest możliwy do oczekiwania. Użycie async def zapewnia, że metoda zwraca obiekt coroutine, który czas wykonywania może wstrzymać i wznowić, utrzymując spójność protokołu nawet dla trywialnych wdrożeń, które po prostu return self.
Jak __aexit__ sygnalizuje tłumienie wyjątków i jaki jest typ jego efektywnej wartości zwrotnej?
__aexit__ musi być metodą coroutine, więc jego wywołanie zwraca obiekt coroutine, na którym interpreter czeka. Czas wykonania Pythona sprawdza wynik tej operacji oczekiwania; jeśli rozwiązana wartość jest prawdziwa (zazwyczaj True), wyjątek jest tłumiony i blok async with kończy się poprawnie. Krytyczny szczegół polega na tym, że zwrócenie True z wewnątrz funkcji async def spełnia ten warunek, ale czas wykonania sprawdza ostateczną rozwiązana wartość, a nie sam obiekt coroutine, co odróżnia to od synchronicznego __exit__, który bezpośrednio zwraca wartość.
W jakich konkretnych warunkach __aexit__ jest wywoływane z argumentami wyjątku ustawionymi na None?
__aexit__ otrzymuje (exc_type, exc_val, exc_tb) jako argumenty, a wszystkie są ustawione na None, dokładnie wtedy, gdy ciało bloku async with kończy się normalnie, nie zgłaszając żadnego wyjątku. To muszą być obowiązkowo obsługiwane, ponieważ logika czyszczenia musi być wykonana bez względu na sukces czy porażkę; kandydaci często piszą implementacje __aexit__, które obsługują tylko przypadki wyjątków, zaniedbując zwalnianie zasobów podczas normalnych wyjść, co prowadzi do wycieków zasobów w długo działających aplikacjach asynchronicznych.