いくつかのライブラリからインポートされた複雑なAPI関数があるとします。
def complex_api_function(
number, <lots of positional arguments>,
<lots of keyword arguments>):
'''really long docstring'''
# lots of code
小さな変更を加えるために、その関数の周りに簡単なラッパーを書きたいと思います。たとえば、最初の引数を文字列として渡すことができるはずです。これを文書化する方法は?私は次のオプションを検討しました:
オプション1:
def my_complex_api_function(number_or_str, *args, **kwargs):
'''
Do something complex.
Like `complex_api_function`, but first argument can be a string.
Parameters
----------
number_or_str : int or float or str
Can be a number or a string that can be interpreted as a float.
<copy paste description from complex_api_function docstring>
*args
Positional arguments passed to `complex_api_function`.
**kwargs
Keyword arguments passed to `complex_api_function`.
Returns
-------
<copy paste from complex_api_function docstring>
Examples
--------
<example where first argument is a string, e.g. '-5.0'>
'''
return complex_api_function(float(number_or_str), *args, **kwargs)
欠点:およびcomplex_api_function
に関する情報を取得するには、ユーザーはのドキュメントを参照する必要が*args
あり**kwargs
ます。コピーからセクションを貼り付けてcomplex_api_function
変更する場合は調整が必要です。
オプション2:
コピーアンドペーストcomplex_api_function
(代わりに使用したのの署名*args
と**kwargs
)とそのドキュメンテーション文字列を。docstringに小さな変更を加え、最初の引数も文字列にすることができることを述べます。例を追加します。
短所:詳細、変更時にcomplex_api_function
変更する必要があります。
オプション3:
飾るmy_complex_api_function
とfunctools.wraps(complex_api_function)
。
欠点:number
文字列になる可能性のある情報はありません。
の変更点の詳細に依存しない答えを探していますmy_complex_api_function
。この手順は、オリジナルを少し調整するだけで機能しcomplex_api_function
ます。
complex_api_function
情報を複製するだけであるため、パラメーターの型が何を期待するかについては触れません(多分それらには複数のオプションもあるかもしれません)。おそらく、ラッパーのユーザーは元の関数にすでに精通しており、そうでない場合は常に元のドキュメントを参照することができます。とにかく、これは進むべき道だと思います。元の関数に追加されたものを文書化し、その新しい型を元の関数に変換する方法の詳細を提供するだけです(これらの詳細は重要かもしれません)。つまり、元の関数との互換性を保つために、その引数がどのように扱われるかです。