Używanie try vs if w pythonie

Czy istnieje uzasadnienie do zadecydować, który z trylub ifkonstrukcje do wykorzystania, podczas testowania zmienna ma wartość?

Na przykład istnieje funkcja, która zwraca listę lub nie zwraca wartości. Chcę sprawdzić wynik przed przetworzeniem. Która z poniższych byłaby lepsza i dlaczego?

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

lub

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

Powiązana dyskusja:

Sprawdzanie istnienia elementu członkowskiego w Pythonie

Często słyszysz, że Python zachęca stylu EAFP („łatwiej jest prosić o przebaczenie niż o pozwolenie”) zamiast stylu LBYL („spójrz, zanim skoczysz ”). Dla mnie to kwestia wydajności i czytelności.

W twoim przykładzie (powiedz, że zamiast zwracać listę lub pusty ciąg, funkcja miała zwrócić listę lub None), jeśli spodziewasz się, że 99% czasu resultfaktycznie będzie zawierało coś iterowalnego, zastosowałbym try/exceptpodejście. Będzie szybciej, jeśli wyjątki są naprawdę wyjątkowe. Jeśli resultjest to Nonewięcej niż 50% czasu, użycie ifjest prawdopodobnie lepsze.

Aby wesprzeć to kilkoma pomiarami:

>>> 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

Tak więc, podczas gdy ifwyciąg zawsze kosztuje, skonfigurowanie try/exceptbloku jest prawie darmowe . Ale kiedy Exceptionfaktycznie nastąpi, koszt jest znacznie wyższy.

Morał:

• Jest całkowicie OK (i „pythonowy”) w użyciu try/exceptdo sterowania przepływem,
• ale ma to sens najbardziej, gdy Exceptionsą naprawdę wyjątkowe.

Z dokumentacji Pythona:

EAFP

Łatwiej prosić o przebaczenie niż o pozwolenie. Ten wspólny styl kodowania w Pythonie zakłada istnienie prawidłowych kluczy lub atrybutów i wyłapuje wyjątki, jeśli założenie okaże się fałszywe. Ten czysty i szybki styl charakteryzuje się obecnością wielu tryi exceptwypowiedzi. Technika kontrastuje ze stylem LBYL wspólnym dla wielu innych języków, takich jak C.

Twoja funkcja nie powinna zwracać typów mieszanych (tj. Listy lub pustego łańcucha). Powinien zwrócić listę wartości lub tylko pustą listę. Wtedy nie musiałbyś niczego testować, tj. Twój kod zwija się do:

for r in function():
    # process items

Proszę zignorować moje rozwiązanie, jeśli dostarczony przeze mnie kod nie jest na pierwszy rzut oka oczywisty i musisz przeczytać wyjaśnienie po przykładzie kodu.

Czy mogę założyć, że „brak zwróconej wartości” oznacza, że ​​zwracana wartość to Brak? Jeśli tak, lub jeśli „brak wartości” jest wartością logiczną False, możesz wykonać następujące czynności, ponieważ Twój kod zasadniczo traktuje „brak wartości” jako „nie iteruj”:

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

Jeśli function()zwraca coś, co nie jest prawdziwe, iterujesz po pustej krotce, tj. Nie uruchamiasz żadnych iteracji. Zasadniczo jest to LBYL.

Twój drugi przykład jest zepsuty - kod nigdy nie zgłosi wyjątku TypeError, ponieważ możesz iterować zarówno przez łańcuchy, jak i listy. Iterowanie po pustym łańcuchu lub liście jest również prawidłowe - spowoduje to zerowe wykonanie treści pętli.

Która z poniższych byłaby lepsza i dlaczego?

W tym przypadku preferowana jest opcja Look Before You Leap. Z wyjątkiem podejścia TypeError może wystąpić w dowolnym miejscu w treści pętli i zostałby przechwycony i wyrzucony, co nie jest tym, czego chcesz i utrudnia debugowanie.

(Zgadzam się jednak z Brandonem Corfmanem: zwracanie Brak dla „brak elementów” zamiast pustej listy jest zepsute. Jest to nieprzyjemny zwyczaj programistów Java, którego nie powinno się widzieć w Pythonie. Lub w Javie).

Ogólnie odnoszę wrażenie, że wyjątki powinny być zarezerwowane dla wyjątkowych okoliczności. Jeśli resultoczekuje się, że nigdy nie będzie pusty (ale może być, na przykład, gdy dysk się zawiesił itp.), Drugie podejście ma sens. Z drugiej strony, jeśli pusty resultjest całkowicie rozsądny w normalnych warunkach, przetestuj go za pomocąif instrukcji ma większy sens.

Miałem na myśli (bardziej powszechny) scenariusz:

# 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

zamiast odpowiednika:

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

bobince mądrze wskazuje, że zawijanie drugiej sprawy może również wychwycić TypeErrors w pętli, co nie jest tym, czego chcesz. Jeśli jednak naprawdę chcesz użyć try, możesz przetestować, czy jest iterowalny przed pętlą

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

Jak widać, jest raczej brzydki. Nie sugeruję tego, ale należy to wspomnieć dla kompletności.

Jeśli chodzi o wydajność, użycie bloku try dla kodu, który normalnie nie generuje wyjątków, jest szybsze niż użycie instrukcji if za każdym razem. Tak więc decyzja zależy od prawdopodobieństwa wyjątkowych przypadków.

Zgodnie z ogólną zasadą, nigdy nie powinieneś używać try / catch ani żadnych rzeczy obsługujących wyjątki do kontrolowania przepływu. Mimo że iteracja za kulisami jest kontrolowana przez wywoływanie StopIterationwyjątków, nadal powinieneś preferować pierwszy fragment kodu od drugiego.