Risposta alla domanda
In Python, le coroutine create tramite async def sono implementate come macchine di stato monouso governate dai flag CO_ITERABLE_COROUTINE o dalle coroutine native a livello di bytecode CPython. Quando chiami una funzione asincrona, restituisce immediatamente un oggetto coroutine contenente un oggetto frame e uno stato di esecuzione; attenderla porta a termine questa macchina di stato, momento in cui il marker interno f_lasti (ultima istruzione) raggiunge la fine e il frame è contrassegnato come esaurito. Il runtime di Python protegge esplicitamente contro il riavvio verificando questo flag di completamento, sollevando RuntimeError se si verificano ulteriori attese, poiché le coroutine sono progettate per rappresentare operazioni asincrone singolari e discrete con un flusso di controllo lineare. Al contrario, le funzioni generatore sono dei fabbriche: ogni invocazione crea un nuovo PyGenObject con il proprio frame di stack indipendente e puntatore d'istruzione, consentendo alla funzione di produrre più iteratori indipendenti che mantengono ciascuno contesti di esecuzione separati.
Situazione dalla vita reale
Un team di sviluppo stava costruendo un client WebSocket resiliente che doveva riprovare i tentativi di connessione falliti utilizzando un ritardo esponenziale. Inizialmente hanno definito una coroutine di connessione a livello di modulo e hanno cercato di riutilizzarla nella logica di ripetizione.
import asyncio async def establish_connection(): return await websockets.connect("wss://api.example.com") # Istanziazione a livello di modulo connection_coro = establish_connection() async def retry_connect(max_attempts=3): for attempt in range(max_attempts): try: ws = await connection_coro # Fallisce alla seconda iterazione return ws except Exception: await asyncio.sleep(2 ** attempt)
Il problema è emerso quando la seconda iterazione del loop ha tentato di attendere nuovamente connection_coro, attivando un RuntimeError poiché il primo await di successo aveva già esaurito l'oggetto coroutine. Il team ha considerato tre soluzioni architetturali.
Un approccio ha comportato la ricostruzione manuale dell'oggetto coroutine all'interno del blocco except dopo aver catturato il RuntimeError. Anche se tecnicamente fattibile, questo ha introdotto una gestione dello stato fragile e ha reso il codice dipendente dal rilevamento dell'esaurimento tramite la gestione delle eccezioni, il che è semanticamente ambiguo e potrebbe mascherare errori di runtime legittimi all'interno della logica di connessione stessa.
Un'altra soluzione proposta prevedeva di convertire establish_connection in una classe che implementasse __await__ per creare un awaitable ripristinabile. Questo forniva un modello di fabbrica ma aggiungeva codice ripetitivo e complessità non necessaria, oscurando l'intento semplice di stabilire una connessione e richiedendo una tracciatura manuale dello stato che duplicava ciò che il runtime di Python fornisce già attraverso le chiamate di funzione.
La soluzione scelta è stata trattare la funzione asincrona come una fabbrica spostando il sito di chiamata all'interno del loop, garantendo che ogni iterazione ricevesse un oggetto coroutine intatto. Rifattorizzando in ws = await establish_connection(), ogni tentativo istanziava una nuova macchina di stato con gestione delle risorse indipendente. Questo era in linea con la filosofia di design di Python in cui le funzioni asincrone sono costruttori per futuri computazionali monouso, risultando in una logica di ripetizione pulita e priva di eccezioni che isolava correttamente i tentativi di connessione falliti dai successivi ripetuti.
Cosa spesso trascurano i candidati
Perché memorizzare una coroutine in una variabile e dimenticare di attenderla crea una perdita di risorse, e come mitiga questo close()?
I candidati spesso assumono che le coroutine non attese semplicemente vengano raccolte come spazzatura senza effetti collaterali. Tuttavia, se una coroutine ha iniziato il proprio corpo e si è sospesa in un'espressione await (ad esempio, mantenendo una connessione a un database o un blocco), il frame mantiene riferimenti a queste risorse. Chiamare close() sull'oggetto coroutine costringe un'eccezione GeneratorExit attraverso il frame, attivando i gestori di contesto (async with) e i blocchi try/finally per rilasciare immediatamente le risorse. Senza un close() esplicito, queste risorse rimangono trattenute fino a quando la raccolta di spazzatura ciclica viene eseguita, il che potrebbe essere troppo tardi per scenari di esaurimento del pool di connessioni.
Qual è la differenza tra async for e await quando si consuma un generatore asincrono, e perché il primo richiede che __aiter__ restituisca il generatore stesso anziché una coroutine?
await consuma una coroutine o un futuro fino al completamento e restituisce un singolo valore, mentre async for itera su un iteratore asincrono, sospendendosi ad ogni yield all'interno di una funzione generatore async def. I candidati confondono async for con l'attesa di un elenco di coroutine. Fondamentalmente, __aiter__ deve restituire direttamente l'oggetto iteratore asincrono (non un awaitable), poiché il runtime di Python chiama __aiter__ in modo sincrono per ottenere l'iteratore prima di iniziare il protocollo di iterazione. Restituire una coroutine da __aiter__ causa un TypeError, poiché il protocollo si aspetta un accesso immediato al metodo __anext__ dell'iteratore per far avanzare la macchina di stato di iterazione asincrona.