11

API の例を見てみましょう

def get_abs_directory(self, path):
    if os.path.isdir(path):
       return path
    else:
       return os.path.split(os.path.abspath(path))[0]

私の質問は、パラメーターを検証するpythonicの方法は何ですか.任意のタイプの検証を無視する必要があります(すべてのpythonコードが検証をまったく行わないことがわかりました)

  1. 「パス」が空でnullではないことを確認する必要があります
  2. パスの「タイプ」が常に文字列であることを確認する必要がありますか
  3. 一般に、パラメーターのタイプを確認する必要がありますか? （動的型付けのPythonほどではないと思います）

この質問はファイル IO に固有のものではありません。代わりに、FileIO は例としてのみ使用されます。

4

4 に答える 4

4

すでに回答済みですが、コメントするには長すぎるので、別の回答を追加します。

一般に、型チェックは 2 つの理由で行われます。関数が実際に完了することを確認することと、不正な出力によるデバッグが困難なダウンストリーム エラーを回避することです。

最初の問題については、答えは常に適切です。EAFP が通常の方法です。悪い入力について心配する必要はありません。

第二に...答えは通常のユースケースに依存し、悪い入力/バグについて心配します. 悪い入力が常に例外を生成する場合、EAFP は依然として適切です (そして、より簡単でデバッグしやすい) (「悪い入力」は、おそらくアプリが生成すると予想される悪い入力の種類に限定できます)。しかし、間違った入力が有効な出力を作成する可能性がある場合、LYBL は後であなたの人生を楽にするかもしれません.

例: square() を呼び出し、この値をディクショナリに入れ、(かなり) 後でこの値をディクショナリから抽出してインデックスとして使用するとします。もちろん、インデックスは整数でなければなりません。

square(2) == 4 であり、有効な整数であり、正しいです。'a'*'a' は無効であるため、 square('a') は常に失敗し、常に例外がスローされます。この 2 つの可能性しかない場合は、EAFP を安全に使用できます。悪いデータを取得した場合は、例外がスローされ、トレースバックが生成されます。pdb で再起動して、何が問題なのかを適切に示すことができます。

ただし...アプリがFPを使用しているとしましょう。また、誤って square(1.43) を呼び出す可能性があります (バグがあると仮定します! もちろん通常の操作ではありません)。これにより、有効な値 (2.0449 程度) が返されます。ここでは例外が発生しないため、アプリは喜んでその 2.0449 を取得し、辞書に入れます。ずっと後になって、アプリはこの値を辞書から取り出し、それをリストのインデックスとして使用し、クラッシュします。トレースバックを取得し、pdb で再起動しますが、それはまったく役に立たないことに気付きます。その値はかなり前に計算されたものであり、入力や、そのデータがどのように取得されたかがわからないためです。そこの。そして、それらはデバッグするのが楽しくありません。

そのような場合、アサート (LYBL の特殊な形式) を使用して、そのような種類のバグの検出を早めるか、明示的に行うことができます。その関数を呼び出すバグがない場合は、どちらでも機能します。しかし、もしそうなら...その後、アプリ内の自然なランダムな場所ではなく、人工的に失敗に近い入力をチェックしたことを本当にうれしく思います。

于 2013-10-21T14:01:08.110 に答える