Utilizzo di try vs if in Python

C'è una logica per decidere quale di tryoif costrutto usare, quando si testa una variabile per avere un valore?

Ad esempio, esiste una funzione che restituisce un elenco o non restituisce un valore. Voglio verificare il risultato prima di elaborarlo. Quale delle seguenti sarebbe più preferibile e perché?

result = function();
if (result):
    for r in result:
        #process items

o

result = function();
try:
    for r in result:
        #process items
except TypeError:
    pass;

Discussione correlata:

Verifica dell'esistenza dei membri in Python

Senti spesso che Python incoraggia lo stile EAFP ("è più facile chiedere perdono che permesso") rispetto allo stile LBYL ("guarda prima di saltare"). Per me è una questione di efficienza e leggibilità.

Nel tuo esempio (dire che invece di restituire un elenco o una stringa vuota, la funzione doveva restituire un elenco o None), se ti aspetti che il 99% delle volte resultconterrà effettivamente qualcosa di iterabile, utilizzerei l' try/exceptapproccio. Sarà più veloce se le eccezioni sono davvero eccezionali. Se resultè Nonepiù del 50% delle volte, l'utilizzo ifè probabilmente migliore.

Per supportare questo con alcune misure:

>>> import timeit
>>> timeit.timeit(setup="a=1;b=1", stmt="a/b") # no error checking
0.06379691968322732
>>> timeit.timeit(setup="a=1;b=1", stmt="try:\n a/b\nexcept ZeroDivisionError:\n pass")
0.0829463709378615
>>> timeit.timeit(setup="a=1;b=0", stmt="try:\n a/b\nexcept ZeroDivisionError:\n pass")
0.5070195056614466
>>> timeit.timeit(setup="a=1;b=1", stmt="if b!=0:\n a/b")
0.11940114974277094
>>> timeit.timeit(setup="a=1;b=0", stmt="if b!=0:\n a/b")
0.051202772912802175

Quindi, mentre ifun'affermazione ti costa sempre , è quasi gratuito impostare un try/exceptblocco. Ma quando si Exceptionverifica effettivamente, il costo è molto più elevato.

Morale:

• È perfettamente OK (e "pythonic") da utilizzare try/exceptper il controllo del flusso,
• ma ha senso soprattutto quando Exceptions sono in realtà eccezionali.

Dai documenti di Python:

EAFP

È più facile chiedere perdono che permesso. Questo stile di codifica Python comune presuppone l'esistenza di chiavi o attributi validi e rileva eccezioni se l'assunzione risulta falsa. Questo stile pulito e veloce è caratterizzato dalla presenza di molte trye exceptaffermazioni. La tecnica contrasta con lo stile LBYL comune a molte altre lingue come C.

La tua funzione non dovrebbe restituire tipi misti (es. Lista o stringa vuota). Dovrebbe restituire un elenco di valori o solo un elenco vuoto. Quindi non dovrai testare nulla, ad esempio il tuo codice collassa per:

for r in function():
    # process items

Ignora la mia soluzione se il codice che fornisco non è ovvio a prima vista e devi leggere la spiegazione dopo l'esempio di codice.

Posso presumere che "nessun valore restituito" significhi che il valore restituito è Nessuno? Se sì, o se "nessun valore" è falso in senso booleano, puoi fare quanto segue, poiché il tuo codice tratta essenzialmente "nessun valore" come "non iterare":

for r in function() or ():
    # process items

Se function()restituisce qualcosa che non è Vero, si scorre sopra la tupla vuota, cioè non si esegue alcuna iterazione. Questo è essenzialmente LBYL.

Il tuo secondo esempio è rotto: il codice non genererà mai un'eccezione TypeError poiché puoi scorrere sia le stringhe che gli elenchi. È anche valido scorrere una stringa o un elenco vuoti: eseguirà il corpo del ciclo zero volte.

Quale delle seguenti sarebbe più preferibile e perché?

In questo caso è preferibile guardare prima di saltare. Con l'approccio dell'eccezione, un TypeError potrebbe verificarsi in qualsiasi punto del corpo del loop e verrebbe catturato e gettato via, il che non è ciò che si desidera e renderebbe difficile il debug.

(Sono d'accordo con Brandon Corfman: la restituzione di None per "nessun elemento" invece di un elenco vuoto è interrotta. È un'abitudine spiacevole per i programmatori Java che non dovrebbe essere vista in Python. O Java.)

In generale, l'impressione che ho avuto è che le eccezioni dovrebbero essere riservate a circostanze eccezionali. Se resultci si aspetta che non sia mai vuoto (ma potrebbe essere, se, ad esempio, un disco si è bloccato, ecc.), Il secondo approccio ha senso. Se, d'altra parte, un vuoto resultè perfettamente ragionevole in condizioni normali, testarlo con unif dichiarazione ha più senso.

Avevo in mente lo scenario (più comune):

# keep access counts for different files
file_counts={}
...
# got a filename somehow
if filename not in file_counts:
    file_counts[filename]=0
file_counts[filename]+=1

invece dell'equivalente:

...
try:
    file_counts[filename]+=1
except KeyError:
    file_counts[filename]=1

bobince sottolinea saggiamente che avvolgere il secondo caso può anche catturare TypeErrors nel loop, che non è quello che vuoi. Se vuoi davvero usare un tentativo, puoi testare se è iterabile prima del ciclo

result = function();
try:
    it = iter(result)
except TypeError:
    pass
else:
    for r in it:
        #process items

Come puoi vedere, è piuttosto brutto. Non lo consiglio, ma dovrebbe essere menzionato per completezza.

Per quanto riguarda le prestazioni, l'utilizzo di try block per il codice che normalmente non genera eccezioni è più veloce dell'utilizzo dell'istruzione if ogni volta. Quindi, la decisione dipende dalla probabilità di casi eccezionali.

Come regola generale, non si dovrebbe mai usare try / catch o qualsiasi altra eccezione che gestisca roba per controllare il flusso. Anche se l'iterazione dietro le quinte è controllata dall'aumento delle StopIterationeccezioni, dovresti comunque preferire il tuo primo frammento di codice al secondo.