傀儡師の館.Python

『IronPythonの世界』を読む (9) の続き、「WebサービスAPIとの連携」P.313 あたりから読む。


IronPythonの世界

Part 5 IronPythonでDB&Webプログラミングの「Yahoo! JAPAN のWebサービスを使う」は P.317 のコードが、インデントすべきところがインデントされてなかったりする。9-12行目や 14-15行目の関数とか、P.318 のprint net["totalResponse..." の行も、113000... の結果の行がくっついてしまっているとか、P.319 でも同じようなのがある。よろしくないところ。とりあえず、同じようなことを安易に 『IronPython の世界』を読む (4) で SlothLib を使ってやってみたので、読み飛ばし。 自然言語処理関連のライブラリ SlothLib をちょこっと使う みたいのをそのうち IronPython で作りなおしてみる(画面のは C# でやっている）。

P.321 「SOAPを使ったWebサービスを利用する」を見ると、PyGoogle などは、内部で socket モジュールや codecs モジュールを使っているから、そのまま IronPython から使えないよという話があり、Visual Studio 2005 から C# か VB でモジュールを作るための簡単な手順が載っている。そんな単純な手順でよいのかいというぐらいあっさりした 10行ほどの記述。でも、やってみると、あっさりビルドできた。確かに Visual Studio からの SOAP は SOAP で便利な世界だなぁ。

とりあえず、SOAP のサービスは IronPython を使えば(C# 等でモジュール作れば）、誰かが作ってモジュールを公開してくれてなくても、5分もあればすぐに IronPython から使えるというのはよいな。

と、また洗脳されてみるｗ

XMLやHTMLを使うでは、SystemXML があるけど、とりあえず CPython の ElementTree を使ってみている。が、expat がなくてエラーになるので IPCE版 (FePy には ElementTree があるからそれを使うのがいい。でも、やっぱり問題があるから手を入れるのがよいですねと、あれこれ書かれている。IPCE r5 の ElementTree だと CPython の正規表現との互換性重視になっているか IronPython 1.0.1 の正規表現モジュールと整合性がとれず、XPath 式でエラーになる。ElementPath.py の正規表現を書き直せばいいかもなどと書かれている。

このあたりやっぱりはまりどころなのね。BeautifulSoup とかどうなんだろうと探すと、[IronPython]BeautifulSoupを使う ということで、FePy なら標準なのね。IPCE-r7 みても確かにある。

なんにせよ、詳しくテストしてみないとどの程度、うまくいくか分からんなぁ。正規の IronPython と、IronPython Community Edition (FePy) との違いとかも、細かく見て、どっちを使うか考えた方がいいとかもあるか。現状どうなっているかも、あとでまとめて確認する。

とりあえず棚上げして先へ進んで、「System.XMLを使う」(p.338)を流し読み。CPython との互換性を考えなければ、こっちが安定して使えるということで洗脳されるｗ

でも、ElementTree を使ったモジュールの流用ができなくなるということだから、やっぱり ElementTree 周り、あとで見直して、試すことにしようかな。

ということで「Webアプリケーションを作る」p346を読む。IIS を使ってのお話なので読み流す。Part 6 「もっと IronPython を使いこなすために」は、「ソースコードを探索しよう」に IronPython 自体のソースコードについてあれこれあって、「IronPython に独自モジュールを追加しよう」とかあって、「.NET Framework 対応の言語から IronPython を使う」と来る。そして「COM相互運用アセンブリを使う」では MSAgent を使った例がある。また、サウンドプレーヤーを使った次のような例も出てくる。

import clr

clr.AddReference("System")

from System.Media import *

player = SoundPlayer()

player.SoundLocation = "bgm.wav"

player.LoadAsync()

player.Play()



『IronPythonの世界』より

時間がかかる処理とか、終わったときに音楽流すようにしとくのに使うかな。APIをさがせば、簡単にすぐに使えるものがたくさんあるというのはやっぱり大きなメリット。Windows だけの世界で OK ならｗ

そして、「デバグの方法」の「ユニットテストを使う」では FePy のにユニットテストが使えるとある。ただし、

IronPythonでIPCEのテストモジュールを使用すると、テスト結果が失敗のときにインポートエラー(pyというモジュールがない）が発生します。
IPCEのインタラクティブシェルで実行するとインポートが発生しません。
IronPythonでもインタラクティブシェルのコマンドライン引数に指定すれば、さきほどのインポートエラーは発生しません。

とある。ふーむ、やっぱりこういうところでも微妙だな問題があるのだな。

そして「Microsoft CLRデバッガを使う」「Visual Studio 2005をデバッガとして使用する」ときて、最後にAppendixnの「IronPythonドキュメントミニツアー」「IronPythonの重要なドキュメント」「.NET Frameworkのライブラリに関するドキュメント」ときて、「Pythonのコミュニティ」「IronPythonとVisualStudio 2005との統合」「IronPythonのサンプル」「Python言語の例外処理」等眺める。

ということで、とりあえず読了ということにする。書くの飽きて来ちゃった。

全般的に見て、ソースコードでおかしいところとかはあるけれど、IronPython を使うなら買うに値する本。この本を読んでからチャレンジした方がはまりどころが明確になっていいし、これ以外にまとまった日本語の情報はないし。

けど、マイクロソフトの人が書いた本だけあって、徐々に、まあ互換性ないところがあってもメリットを活かせばよいかとやんわりと洗脳されていくが、2800円の元は十分取れると思う。

IronPython は、Python が好きな人が Windows の世界の資産を有効活用するにはとてもよい。

けれども CPython の遺産を使おうとすると、まだまだ苦労する。互換性の問題をいろいろ考慮しなければならないから。小さいものなら書き換えを適当にやれないことはないだろうけど、大きいものだと検証も含めて手間がかかるから開発コストの点では効率的とはいえない。FePy がもっと進んだら、ステキかもしれない。

Ironclad 0.2 Released: Use CPython Extensions from IronPython (Nearly...) みたいのも、始まっているから、IronPython から C 拡張を使えるようになってくる。そうすると何でもありでとっても強力な環境になるだろう。