Come denominare il parametro che contiene il middleware 'successivo' nella catena?

Question

Come denominare il parametro che contiene il middleware 'successivo' nella catena?

#1 da (0 voti)
#2 da (0 voti)

-3

Sto scrivendo un'implementazione della catena del middleware in Python. Ecco come appare una funzione middleware:

async def logger(ctx, next):
    print(f"Started doing stuff with {ctx}")
    await next()
    print(f"Finished doing stuff with {ctx}")

E questo è il modo in cui lo usi:

app.use(logger)
app.use(some_other_middleware)
app.use(process_request)
...

L'argomento

next è il riferimento indiretto al prossimo middleware nella catena. In Javascript, da cui traggo ispirazione per questo design, è molto comune denominare questo argomento next . Tuttavia, in Python next è già una funzione incorporata, ed è meglio non oscurarlo. Inoltre, i linters di codice si lamentano di nascondere un builtin.

Quindi, devo trovare un nome alternativo che sia allo stesso livello chiaro, breve e leggibile. Sfortunatamente, l'inglese non è la mia prima lingua, quindi non vedo alcuna alternativa e le cose inventate come _next , next_ o anext mi sembrano estremamente brutte.

Qualche suggerimento?

naming python-3.x

posta toriningen 20.07.2017 - 03:33

fonte

2 risposte

0

Quando si nomina il middleware WSGI, di solito uso la parola "app".

L'app è l'applicazione che il middleware attuale sta eseguendo il wrapping. L'applicazione potrebbe effettivamente essere un'applicazione che è stata avvolta da un altro middleware, ma il middleware attuale non ha bisogno di preoccuparsene, poiché un'applicazione middleware wrapper è ancora un'applicazione.

Perché questo è un nome migliore di next ? Perché è un nome.

risposta data 20.07.2017 - 05:43

fonte

Leggi altre domande sui tag naming python-3.x

Aiuto di progettazione necessario Qual è la differenza tra Listener HTTP e un webservice

score 0 · Accepted Answer

In questo caso specifico ho eluso la necessità di denominare l'argomento passando a generatori asincroni:

async def logger(ctx):
    print(f"Started doing stuff with {ctx}")
    yield
    print(f"Finished doing stuff with {ctx}")

Per me questo sembra essere migliore di next , perché sta usando la semantica del linguaggio.

Se non avessi cambiato, avrei usato proceed :

async def logger(ctx, proceed):
    print(f"Started doing stuff with {ctx}")
    await proceed()
    print(f"Finished doing stuff with {ctx}")