** kwargsはアンチパターンですか？

ライブラリを内部的に呼び出す内部コードベースには多くのコードがあります-これらのライブラリには多くの引数があり（matplotlibを考えてください）、コードは特定のタスクのみを実行し、**kwargs呼び出された次の関数に単純に渡します。

例えば：

def our_method(dataframe, **kwargs):
    result = do_something_with_data(dataframe)
    external_module.draw(result, **kwargs)

一方で**kwargs私たちのメソッド宣言のすべてのパラメータを繰り返すことから防止たちを、それはまた、呼び出し時に引数が有効であることが非常に不透明になりour_method、私はと呼ばれる方法を知っている必要があり、私は頻繁に知られたくないています- 。

これについてどう思いますか？

開発者はどのようにコードを使用しますか？言い換えれば、どの引数をどのように使用すべきかを決定するために、彼らは正確に何をしますか？

• コードから自動的に生成されたドキュメントに依存しており、ジェネレーターが何をすべきか分からない**kwargs場合、これは確かに問題です。ドキュメンテーションで引数のリストとその意味を見つける代わりに、曖昧な「いくつかの引数をとる」以外の情報はまったくありません。

  この問題はおそらく、メソッドを手動で文書化し、自動的に生成された文書を置き換えることで解決される可能性があります。これには、メソッドの実装者からの追加の作業が必要ですが、コード（およびそのドキュメント）は、書かれているよりもはるかに頻繁に読み取られることを忘れないでください。

• コードがドキュメントである場合、メソッドを使用する開発者には**kwargs2つの追加手順が必要です。メソッドのシグネチャだけでなく、実際に呼び出す他のメソッドを見つけるために、実際の実装も確認する必要があります。その後、彼らは最終的に彼らが探していたものを見つけるためにこの他の方法に行く必要があります。

  これには多くの努力は必要ありませんが、それでもなお、この努力を何度も繰り返す必要があります。最悪の部分は、ドキュメントを追加することで彼らを助けることができないということです：実際の引数をリストしてメソッドにコメントすると、メソッドが呼び出すライブラリの次のバージョンが異なる引数を持ち、ドキュメントが異なるという大きなリスクがあります誰もそれを最新に保つ必要があることを思い出さないので、時代遅れになります。

私の推奨事項は、**kwargsスコープが縮小されたメソッドのみに依存することです。_たとえば、クラス内のいくつかの場所で使用されるプライベートメソッド（およびPythonのコンテキストではprivateで始まるメソッドを意味します）は、良い候補です。一方、コードベース全体で数十のクラスで使用されるメソッドは非常に悪い候補です。

結局のところ、記述するメソッド内で呼び出すメソッドの引数を書き換えるのに、それほど労力を費やすべきではありません。うまくいけば、ほとんどのメソッドは6〜8個以上の引数をとらないでください。もしそうなら、コードをリファクタリングするべきではないかどうかを自問してください。すべての場合：

• メソッド内で引数を明示的に指定するのに多くの労力は必要ありませんが、

• とにかく引数を検証したい場合があります（ただし、引数を明示するためにこの点のみに依存している場合、YAGNIに違反します）。

次のレベルの関数に__doc__がある場合は、__ doc__を新しい関数にコピーするだけです。

例えば：

def a(x):
    """This function takes one parameter, x, and does nothing with it!"""
    pass

def b(**kwargs):
    a(**kwargs)

b.__doc__=a.__doc__

これは再帰的に適用でき、デコレータによって適用できます（とにかくこれを一括して行う場合に便利です）。__doc__文字列も操作して、末尾にさらに追加できます。これは、表示されるパラメーターがまだkwargsであることを意味しますが、少なくとも実際のパラメーターを説明するドキュメントがヘルプにあります。