]追加された行はこの色です。削除された行はこの色です。あるデコレータを使おうとしたら、オブジェクトメソッドの対応を考慮されていなかった。最悪そのデコレータだけ書き直せばいいのですが、バージョンアップ等に対応するのが面倒だし、あまりいじりたくない。そんな場合に無理矢理オブジェクトメソッドに対応させるデコレータを考えてみました。オブジェクトメソッドに対応するには第一引数がオブジェクトの場合を考慮しておかなければなりませんが、そういう処理がされていなかった場合にどう対応するか?というお話しです。Djangoを使っていた話。1.5(おそらくそれ以前も)、のdjango.views.decorators.http.require_http_methodsデコレータ(以降require_http_methods)はリクエストのメソッドを制限するデコレータであり、通常はviewsに適用されます。Djangoではviewsは関数として実装することになってい(たぶん)ますが、viewsをオブジェクトメソッドとして実装すると以下のようになります。urls.pyにはメソッドオブジェクトとして渡せばコールすることは可能ですが、第一引数にselfが入るので、以下の例外を吐きます。require_http_methodsは第一引数はHttpRequestオブジェクト決めうちなので、MyViewオブジェクトが渡されてしまうとAttributeErrorになってしまいます。そこで、require_http_methodsへの引数はselfを除いたもの、しかし元のメソッドにはselfを含めて渡すという、なかなかトリッキーな手法を採ることになります。頭がこんがらがりながらも実現したのが以下。※検索すればわかりやすい解説はいくらでもあるので詳しくは述べませんが、デコレータを通したコールは以下と同様です。MyViewの場合は以下。require_http_methodsをデコレートするデコレータを定義。viewsは以下のようにします。これで、無理矢理動かすことができます(^^;。デコレータの動作はややこしいので肝心の部分だけを説明します。executable_decoratorの中でfという関数を定義していますが、これは一種のカリー化であり(用語として正しい?)、元の関数funcに対してselfをあらかじめクロージャに入れてしまい、引数の数を変えています。これをrequire_http_methodsでラップすることで本来第一引数であるオブジェクト(self)を無視することができるわけです。ここまでするメリットがどの程度かは分かりませんが、まあ、頭の体操と言うことで。デコレータ用のデコレータっていうところでややこしかったです。普段カリー化とか使っている人には当たり前の手法かも知れませんが、結構悩んだのでメモしておきます。追加解説などあればコメント戴けるとうれしいです(^^)。