🐍pythonのデコレータ PEP318

2024年5月5日 08:58

関数定義は一つ以上のデコレータ式でラップできます。デコレータ式は関数を定義するとき、関数定義の入っているスコープで評価されます。その結果は、関数オブジェクトを唯一の引数にとる呼び出し可能オブジェクトでなければなりません。関数オブジェクトの代わりに、返された値が関数名に束縛されます。複数のデコレータはネストして適用されます。

https://docs.python.org/ja/3/reference/compound_stmts.html#grammar-token-python-grammar-decorator

概要
関数やメソッドを変換する現在の方法（例えば、クラスやスタティックメソッドとして宣言する）は厄介で、理解しにくいコードになる可能性がある。理想的には、これらの変換は、宣言そのものが行われるコードの同じ箇所で行われるべきです。このPEPでは、関数やメソッド宣言の変換に新しい構文を導入します。
動機
関数やメソッドに変換を適用する現在の方法は、実際の変換を関数本体の後に置きます。大きな関数の場合、これは関数の動作の重要なコンポーネントを、関数の外部インターフェイスの残りの部分の定義から分離してしまいます。例えば

https://peps.python.org/pep-0318/

def foo(self):
    perform method operation
foo = classmethod(foo)

これは長いメソッドでは読みにくくなります。また、概念的には1つの宣言である関数に3回も名前をつけるのはpythonicではありません。この問題の解決策は、メソッドの変換をメソッド自身の宣言に近づけることです。新しい構文の意図は

def foo(cls):
    pass
foo = synchronized(lock)(foo)
foo = classmethod(foo)

を、関数の宣言に装飾を置くという代替案で置き換えることができる：

@classmethod
@synchronized(lock)
def foo(cls):
    pass

この方法でクラスを変更することも可能だが、その利点はすぐにはわからない。ほぼ間違いなく、クラスデコレーターでできることはすべてメタクラスでもできますが、メタクラスを使うことは十分にわかりにくいので、クラスを簡単に修正する方法があることは魅力的です。Python 2.4 では、関数/メソッドデコレータのみが追加されています。

なぜこんなに難しいのか？

Pythonではバージョン2.2から2つのデコレータ（classmethod()とstaticmethod()）が使えるようになりました。その頃から、いずれ何らかの構文的なサポートがPythonに追加されるだろうと思われていました。この前提を考えると、なぜコンセンサスを得るのが難しいのか不思議に思うかもしれません。comp.lang.python と python-dev メーリングリストの両方で、関数デコレータをどのように実装するのがベストなのか、議論が交わされてきました。なぜそうしなければならないかという明確な理由はありませんが、いくつかの問題が最も意見が分かれているようです。

意図の宣言」がどこに属するかについての意見の相違。

関数の定義の最後で装飾や変換を行うのは最適ではないという点では、ほぼ全員が同意している。それ以上に、この情報をどこに置くべきかについての明確なコンセンサスはないようだ。
構文上の制約 Pythonは構文的に単純な言語であり、(視覚的にも言語パーサに関しても) "物事を台無しにする "ことなく何ができて何ができないかについて、かなり強い制約があります。この概念を初めて知った人たちが、"ああ、そうだ、何をやっているのかわかった "と思うように、この情報を構造化する明白な方法はない。可能だと思われる最善の方法は、新しいユーザーが構文が意味するものについて、荒唐無稽な間違ったメンタル・モデルを作らないようにすることである。
コンセプトに対する全体的な不慣れさ。代数学（あるいは基本的な算数）を一通り知っている人や、他のプログラミング言語を少なくとも1つ使ったことがある人にとっては、Pythonの多くは直感的です。Pythonでデコレータの概念に出会う前に、デコレータの概念に触れたことがある人はほとんどいないでしょう。この概念を捉える強力な既存のミームがないのです。
一般的に構文の議論は、他の何よりも多くの論争を引き起こすようです。PEP 308に関連した三項演算子の議論もその一例です。

背景

現状では構文サポートが望ましいというのが一般的な意見です。Guido は第10回 Python カンファレンスの DevDay 基調講演でデコレータの構文サポートについて言及しました。Michael Hudsonはカンファレンスの直後にpython-devでこのトピックを取り上げ、最初の括弧付き構文はGareth McCaughanによるcomp.lang.pythonでの以前の提案によるものだとしました。

クラス定義と関数定義は構文的に似ているので、クラス装飾は明らかな次のステップのように思えますが、Guido はまだ納得しておらず、クラス装飾は Python 2.4 にはほとんどないでしょう。

この議論は2002年2月から2004年7月までpython-devで継続されました。何百もの投稿がなされ、人々は多くの可能な構文のバリエーションを提案しました。Guidoは提案のリストをEuroPython 2004に持って行き、そこで議論が行われました。その後、彼はJavaスタイルの@decorator構文を持つことに決め、2.4a2で初めて登場しました。Barry Warsaw はこれを 'pie-decorator' 構文と名付けました。これは、デコレータ構文と同時期に起こった Pie-thon Parrot shootout にちなんでおり、また @ が少しパイに似ているからです。Guido は Python-dev で、却下された(多くの)フォームに関するこの記事を含め、彼のケースを概説しました。

デコレーター」という名前について

この特集に「デコレーター」という名前を選んだことについては、多くの不満がある。主なものは、この名前がGoFブックでの使い方と一貫していないということです。decorator'という名前は、おそらくコンパイラの分野での使用、つまりシンタックスツリーを歩きながら注釈をつけることに由来しているのだろう。もっといい名前があるかもしれない。

設計目標

新しい構文は

ユーザー定義の callable や、既存の組み込み関数 classmethod() や staticmethod() を含む、任意のラッパーで動作すること。この要件は、デコレータ構文がラッパーコンストラクタへの引数の受け渡しをサポートしなければならないことも意味します。
定義ごとに複数のラッパーを扱うことができます。
何が起こっているのかが一目瞭然であること。少なくとも、新しいユーザーが自分のコードを書くときに、それを無視しても大丈夫なように一目瞭然であること。
一度説明すれば...覚えやすい」構文であること。
将来の拡張を難しくしない
入力が簡単であること。この構文を使うプログラムは、非常に頻繁にこの構文を使うことが予想される。
コードを素早くスキャンすることを難しくしないこと。すべての定義、特定の定義、あるいは関数が受け付ける引数を検索するのは、依然として簡単でなければならない。
言語依存のエディターや他の "おもちゃのパーサーツール "のような二次的なサポートツールを不必要に複雑にしない。
将来のコンパイラがデコレータを最適化できるようにする。PythonのJITコンパイラがいずれ登場することを期待すると、デコレータの構文を関数定義の前に置く必要があります。
現在は隠されている関数の末尾から、もっと目につきやすい前方へ移動します。
Andrew Kuchling氏のブログには、動機と使用例に関する多くの議論へのリンクがある。特に注目すべきはJim Hugininのユースケースのリストだ。

Python 2.4a2で実装されている関数デコレーターの現在の構文は以下の通りです：

@dec2
@dec1
def func(arg1, arg2, ...):
    pass

は、だいたい次と等価です

def func(arg1, arg2, ...):
    pass
func = dec2(dec1(func))

を変数funcに代入する必要はない。デコレーターは関数宣言の近くにある。記号は、ここで何か新しいことが起こっていることを明らかにしている。

適用順序（下から上）の根拠は、関数適用の通常の順序と一致しているからである。数学では、関数の合成(g o f)(x)はg(f(x))と訳される。Pythonでは、@g @f def foo()はfoo=g(f(foo))となる。

デコレーター・ステートメントが受け入れることができるものは限られており、任意の式は機能しない。グイドは直感的にこれを好んだ。

現在の構文では、デコレーター宣言でデコレーターを返す関数を呼び出すこともできる：

@decomaker(argA, argB, ...)
def func(arg1, arg2, ...):
    pass

は、だいたい次と等価です

func = decomaker(argA, argB, ...)(func)

デコレーターを返す関数を持つ根拠は、@記号の後を式とみなすことができ（構文的には単なる関数に限定されるが）、その式が返すものは何でも呼び出されるからである。宣言引数を参照。

なぜ@なのか？

Javaでは、最初はJavadocコメントの目印として、その後Java 1.5でPythonのデコレーターに似たアノテーションに@を使った歴史がある。Pythonで@がトークンとして使われていなかったということは、そのようなコードが以前のバージョンのPythonで解析される可能性がないということでもあり、微妙な意味上のバグにつながる可能性があります。また、何がデコレーターで何がデコレーターでないかという曖昧さが取り除かれたことも意味します。とはいえ、@はまだかなり恣意的な選択です。代わりに｜を使うことを提案する人もいる。

デコレータを指定するためにリストのような構文を使う構文オプションについては、いくつかの選択肢が提案された： [...|]、[...]、そして<...>である。

Pythonのデコレータは関数型プログラミングのコンセプトといくつかの類似点があります。具体的には以下の点が挙げられます。

高階関数 (Higher-Order Functions):
デコレータは関数を引数として受け取り、新しい関数を返す高階関数の一種です。関数型プログラミングでも、高階関数は基本的な概念の一つです。
関数の合成 (Function Composition):
デコレータを使用すると、関数の前後に追加の処理を組み込むことができます。これは関数を合成することで新しい機能を持たせる、関数型プログラミングの概念に類似しています。
イミュータビリティ (Immutability):
デコレータは既存の関数を変更するのではなく、新しい関数を作成します。これは関数型プログラミングで重視されるイミュータビリティの考え方に合致します。
デコレータチェーン (Decorator Chain):
複数のデコレータをチェーンすることで、関数に対して複数の修飾を適用できます。これも関数型プログラミングの関数合成の考え方に似ています。

これらの点から、Pythonのデコレータは関数型プログラミングのコンセプトと密接に関連していると言えます。

お願い致します