実装の詳細です。引数を取得する Python C API は、位置引数とキーワード引数を分離します。位置引数には、内部的に名前さえありません。
operator.add
関数 (および のような同様のもの)の引数を取得するために使用されるコードsub
は次のとおりです。
PyArg_UnpackTuple(a,#OP,2,2,&a1,&a2)
ご覧のとおり、引数名は含まれていません。関連するコード全体operator.add
は次のとおりです。
#define spam2(OP,AOP) static PyObject *OP(PyObject *s, PyObject *a) { \
PyObject *a1, *a2; \
if(! PyArg_UnpackTuple(a,#OP,2,2,&a1,&a2)) return NULL; \
return AOP(a1,a2); }
spam2(op_add , PyNumber_Add)
#define spam2(OP,ALTOP,DOC) {#OP, op_##OP, METH_VARARGS, PyDoc_STR(DOC)}, \
{#ALTOP, op_##OP, METH_VARARGS, PyDoc_STR(DOC)},
spam2(add,__add__, "add(a, b) -- Same as a + b.")
ご覧のとおり、a
とb
が使用されている場所は docstring だけです。METH_KEYWORDS
メソッド定義は、メソッドがキーワード引数を受け入れるために必要なフラグも使用しません。
一般的に言えば、引数名がわかっているpythonベースの関数は常にキーワード引数を受け入れると安全に想定できます(もちろん、誰かが解凍して厄介なことをすることができます*args
が、引数が正常に見える関数ドキュメントを作成できます).キーワード引数を受け入れない場合があります。いくつかの引数またはオプションの引数を持つ関数が、後の/オプションの引数のキーワード引数を受け入れる可能性は十分にあります。しかし、あなたはほとんどそれをテストする必要があります.
python-ideas メーリングリストのあらゆる場所で、キーワード引数のサポートに関する議論を見つけることができます。また、 Guido van Rossum (慈悲深い終身独裁者、別名 Python の作成者)の声明もあります。
うーん。ord(char=x) の例が示すように、多くの (ほとんどの?) 1-arg 関数と選択された 2-arg 関数 (およびめったに 3+-arg 関数) では、これにより読みやすさが低下すると思います。
私は実際には、引数をキーワード引数として指定できないことを示す構文上の機能を見たいと思っています (キーワードでなければならないことを示す構文を既に追加したように)。
キーワード引数の追加が完全に間違っていると私が思う領域の 1 つは、組み込み型または ABC のメソッドであり、オーバーライド可能であることです。たとえば、dict の pop() メソッドを考えてみましょう。引数名は現在文書化されていないため、誰かが dict をサブクラス化してこのメソッドをオーバーライドした場合、またはダックタイピングを使用して dict をエミュレートしようとする別の可変マッピング クラスを作成した場合、引数名が何であるかは問題ではありません -- すべての呼び出し元 ( dict、dict サブクラス、または dict のようなアヒルを期待する) は、呼び出しで位置引数を使用します。しかし、pop() の引数名を文書化して、ユーザーがこれらを使い始めると、ほとんどの dict サブクラスとダックが突然壊れてしまいます (偶然にも同じ名前を選んだ場合を除く)。