Odpowiedź na pytanie
W Pythonie, korutyny utworzone przy pomocy async def są realizowane jako maszyny stanowe jednorazowego użytku, kierowane przez flagi CO_ITERABLE_COROUTINE lub flagi natywnych korutyn na poziomie bajtowego kodu CPython. Kiedy wywołujesz funkcję asynchroniczną, natychmiast zwraca obiekt korutyny zawierający obiekt ramki i stan wykonania; oczekiwanie na nią prowadzi tę maszynę stanową do zakończenia, w momencie, w którym wewnętrzny znacznik f_lasti (ostatnia instrukcja) osiąga koniec, a ramka jest oznaczana jako wyczerpana. Środowisko uruchomieniowe Python wyraźnie chroni przed ponownym wejściem, sprawdzając ten znacznik zakończenia, zgłaszając RuntimeError, jeśli wystąpią kolejne oczekiwania, ponieważ korutyny mają na celu reprezentowanie pojedynczych, dyskretnych operacji asynchronicznych z liniowym przepływem sterowania. Z kolei funkcje generatorów są fabrykami—każde wywołanie tworzy nowy obiekt PyGenObject z niezależnym stosu ramki i wskaźnikiem instrukcji, co pozwala funkcji na generowanie wielu niezależnych iteratorów, z których każdy utrzymuje oddzielne konteksty wykonawcze.
Sytuacja z życia
Zespół deweloperski budował odporny klient WebSocket, który musiał ponawiać nieudane próby połączenia, stosując wykładnicze opóźnienie. Początkowo zdefiniowali korutynę połączeniową na poziomie modułu i próbowali wykorzystać ją w logice ponawiania.
import asyncio async def establish_connection(): return await websockets.connect("wss://api.example.com") # Instancjonowanie na poziomie modułu connection_coro = establish_connection() async def retry_connect(max_attempts=3): for attempt in range(max_attempts): try: ws = await connection_coro # Nieudane w drugiej iteracji return ws except Exception: await asyncio.sleep(2 ** attempt)
Problem pojawił się, gdy druga iteracja pętli próbowała ponownie oczekiwać connection_coro, co spowodowało RuntimeError, ponieważ pierwsze pomyślne oczekiwanie już wyczerpało obiekt korutyny. Zespół rozważył trzy rozwiązania architektoniczne.
Jednym z podejść była manualna rekonstrukcja obiektu korutyny w bloku except po złapaniu RuntimeError. Choć technicznie możliwe, wprowadziło to kruchą obsługę stanu i uczyniło kod zależnym od wykrywania wyczerpania za pomocą obsługi wyjątków, co jest semantycznie niejednoznaczne i może maskować legitymne błędy wykonania w samej logice połączenia.
Inne rozwiązanie zaproponowało przekształcenie establish_connection w klasę implementującą __await__, aby stworzyć resetowalny obiekt oczekujący. To zapewniło wzorzec fabryczny, ale dodało niepotrzebny kod i złożoność, zasłaniając prosty zamiar nawiązania połączenia i wymagając ręcznego śledzenia stanu, co dublowało to, co środowisko uruchomieniowe Python już zapewnia poprzez wywołania funkcji.
Wybrane rozwiązanie polegało na traktowaniu funkcji asynchronicznej jako fabryki, przenosząc miejsce wywołania wewnątrz pętli, co zapewniło, że każda iteracja otrzymywała nieskazitelny obiekt korutyny. Poprzez refaktoryzację do ws = await establish_connection(), każda próba instancjonowała świeżą maszynę stanową z niezależnym zarządzaniem zasobami. To było zgodne z filozofią projektowania Python, gdzie funkcje asynchroniczne są konstruktorami jednorazowych przyszłości obliczeniowych, co skutkowało czystą, wolną od wyjątków logiką ponawiania, która odpowiednio izolowała nieudane próby połączenia od subsequentnych prób.
Co często pomijają kandydaci
Dlaczego przechowywanie korutyny w zmiennej i zapomnienie o oczekiwaniu na nią tworzy wyciek zasobów, a jak close() łagodzi to?
Kandydaci często zakładają, że nieoczekiwane korutyny po prostu zbierają śmieci bez efektów ubocznych. Jednak jeśli korutyna weszła do swojego ciała i zawiesiła się na wyrażeniu await (na przykład, trzymając połączenie z bazą danych lub blokadę), rama utrzymuje odniesienia do tych zasobów. Wywołanie close() na obiekcie korutyny wymusza wyjątek GeneratorExit przez ramkę, co powoduje natychmiastowe uwolnienie zasobów za pomocą menedżerów kontekstu (async with) i bloków try/finally. Bez wyraźnego close(), te zasoby pozostają zajęte, aż cykliczna kolekcja śmieci się uruchomi, co może być za późno w scenariuszach wyczerpania puli połączeń.
Jak inspect.iscoroutine() różni się od inspect.isawaitable(), i dlaczego to rozróżnienie ma znaczenie przy pisaniu ogólnych narzędzi asyncio?
inspect.iscoroutine() zwraca True tylko dla natywnych obiektów korutyn stworzonych przez funkcje async def, podczas gdy inspect.isawaitable() zwraca True dla dowolnego obiektu implementującego __await__, w tym korutyn, zadań, przyszłości i niestandardowych obiektów oczekujących. Kandydaci nie dostrzegają, że funkcje asyncio, takie jak ensure_future(), akceptują dowolny obiekt oczekujący, a nie tylko korutyny. Pisanie bibliotek, które surowo sprawdzają iscoroutine(), odrzuca ważne obiekty oczekujące, takie jak asyncio.Queue().get() lub niestandardowe obiekty przyszłości, łamiąc polimorfizm w ogólnych funkcjach narzędziowych zaprojektowanych do planowania dowolnych operacji asynchronicznych.
Jaka jest różnica między async for a await podczas konsumowania asynchronicznego generatora, i dlaczego to pierwsze wymaga, aby __aiter__ zwracało generator sam w sobie, a nie korutynę?
await konsumuje korutynę lub przyszłość do zakończenia i zwraca jedną wartość, podczas gdy async for iteruje po asynchronicznym iteratorze, zatrzymując się na każdym yield wewnętrz funkcji generatora async def. Kandydaci mylą async for z oczekiwaniem na listę korutyn. Kluczowe jest to, że __aiter__ musi zwracać obiekt asynchronicznego iteratora bezpośrednio (a nie obiekt oczekujący), ponieważ środowisko uruchomieniowe Python wywołuje __aiter__ synchronicznie, aby uzyskać iterator przed rozpoczęciem protokołu iteracji. Zwrócenie korutyny z __aiter__ powoduje TypeError, ponieważ protokół oczekuje natychmiastowego dostępu do metody __anext__ iteratora, aby napędzać maszynę stanową asynchronicznej iteracji.