Pythonでtry vs ifを使用する

変数に値があるかどうかをテストするときに、tryどちらifを使用するかを決定する根拠はありますか？

たとえば、リストを返すか、値を返さない関数があります。処理する前に結果を確認したい。次のうちどれがより好ましいでしょうか、それはなぜですか？

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

または

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

関連ディスカッション：

Pythonでのメンバーの存在の確認

PythonはLBYLスタイル（「ジャンプする前に見る」）よりもEAFPスタイル（「許可よりも許しを求める方が簡単」）を奨励しているとよく耳にします。私にとって、それは効率と読みやすさの問題です。

あなたの例では（リストまたは空の文字列を返す代わりに、関数がリストまたはを返すことになったとしますNone）、99％の時間resultに実際に反復可能な何かが含まれることが予想される場合は、このtry/exceptアプローチを使用します。例外が本当に例外的である場合、それはより速くなります。が時間の50％を超える場合resultはNone、使用することifをお勧めします。

いくつかの測定でこれをサポートするには：

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

したがって、ifステートメントは常にコストがかかりますが、try/exceptブロックを設定することはほぼ無料です。しかし、Exception実際に発生すると、コストははるかに高くなります。

道徳の：

• try/exceptフロー制御に使用することは完全に（そして「pythonic」）、
• しかし、Exceptionsが実際に例外的である場合、それは最も理にかなっています。

Pythonのドキュメントから：

EAFP

許可より許しを求める方が簡単です。この一般的なPythonコーディングスタイルは、有効なキーまたは属性の存在を想定しており、想定が誤っていることが判明した場合は例外をキャッチします。このクリーンで速いスタイルは、多数のtryand exceptステートメントの存在によって特徴付けられ ます。この技法は、 Cなどの他の多くの言語に共通のLBYLスタイルとは対照的です。

関数は混合型（リストまたは空の文字列）を返すべきではありません。値のリストまたは空のリストのみを返す必要があります。その後、何もテストする必要はありません。つまり、コードは次のように折りたたまれます。

for r in function():
    # process items

私が提供するコードが一見明白ではなく、コードサンプルの後に説明を読む必要がある場合は、私のソリューションを無視してください。

「戻り値なし」は戻り値がNoneであることを意味すると思いますか？はいの場合、または「値なし」がブール値でFalseの場合、コードは基本的に「値なし」を「反復しない」として扱うため、次のことを実行できます。

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

function()Trueでないものを返す場合は、空のタプルを反復処理します。つまり、反復を実行しません。これは本質的にLBYLです。

2番目の例は壊れています。文字列とリストの両方を反復処理できるため、コードがTypeError例外をスローすることはありません。空の文字列またはリストを繰り返し処理することも有効です。ループの本体を0回実行します。

次のうちどれがより好ましいでしょうか、それはなぜですか？

この場合は、Leap Before You Leapが望ましいです。例外アプローチを使用すると、TypeErrorがループ本体の任意の場所で発生する可能性があり、キャッチされて破棄されるため、デバッグが難しくなります。

（しかし、私はBrandon Corfmanに同意します。空のリストの代わりに「アイテムなし」に対してNoneを返すのは失敗します。これは、Pythonでは見られないはずのJavaプログラマーの習慣です。Javaでは。）

一般に、私が得た印象は、例外は例外的な状況のために予約する必要があるということです。resultが空になることが予想されない場合（ただし、ディスクがクラッシュした場合など）は、2番目のアプローチが有効です。一方、空resultが通常の条件下で完全に妥当である場合は、ifステートメントを使用してそれをテストする方が理にかなっています。

（より一般的な）シナリオを念頭に置いていました：

# 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

同等のものの代わりに：

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

bobinceは、2番目のケースをラップすることでループ内のTypeErrorsもキャッチできることを賢明に指摘していますが、これは望ましいことではありません。実際に試してみたい場合は、ループの前に反復可能かどうかをテストできます

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

ご覧のとおり、かなり醜いです。お勧めはしませんが、完全を期すために言及する必要があります。

パフォーマンスに関する限り、通常は例外を発生させないコードにtryブロックを使用する方が、毎回ifステートメントを使用するよりも高速です。したがって、決定は例外的なケースの確率に依存します。

一般的な経験則として、フローを制御するために、try / catchなどの例外処理機能を使用しないでください。舞台裏での反復はStopIteration例外の発生によって制御されますが、2番目よりも最初のコードスニペットを優先する必要があります。