IronPython 2.6 ベータ2

リリースノート
http://ironpython.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=27350
によると、

バグ修正のほかに、pdbや_ctypesが強化されてるようです。

pdb（デバッガーむけのインターフェイス）と聞いて、ひょっとしてpydevと一緒に使ったらeclipse上でステップ実行できるかも？と思って試してみましたが、まだ動かないようです。

もし動いたら、Java（Sunというかオラクル）で記述されたEclipse（IBM）上でPython（Google）とコンパチのIronPython（MS）インタプリタでデバッグ、という摩訶不思議な図になるのですが・・・

64ビットWindowsへの対応として、ipy.exe以外に、ipy64.exeが用意されたそうですが、リリースノートの説明を読んで一瞬「？」。

・ipy.exeは64ビットOSでも32ビットOSでも32ビットプロセスとして実行される。
・ipy64.exeは64ビットOSで動かすと64ビットプロセスとして、32ビットOSだと32ビットプロセスとして実行される。

この説明を、OSの方から整理してみます。

・64ビットOSでは、ipy.exeは32ビットプロセス、ipy64.exeは64ビットプロセスとして実行される。
・32ビットOSでは、ipy.exeもipy64.exeも32ビットプロセスとして実行される。

これでやっと腑に落ちました。コンパイルして配布するバッチプロセスでIronPythonを呼び出すときを想定してこうなってるんだなあ、と。

・32ビットプロセスとして実行したいときはipy.exeと書いておけば良い。
・64ビットプロセスとして実行したいときはipy64.exeと書いておけばよい。ただし、32ビットOSで実行された場合には、いきなり「64ビットOS用のコードは実行できません」エラーで終了するのではなく、32ビットプロセスとして実行してみる。

という動作になります。

(同日追記)

32ビットのマシンにインストールするとipy64.exeがコピーされない（あるいは作られない）ところを見ると、上記はバッチファイルよりはコンパイルしたものを想定した動作のようです。

Re: IronPythonでマルチプラットフォームGUIの可能性 番外編

記事「MicrosoftはC#とCLIに特許を主張せず - .NET互換「Mono」への影響は?」
http://journal.mycom.co.jp/news/2009/07/09/019/index.html
より。

C#やCLIのうち、ECMAがカバーしている（つまり標準化された）部分については「Microsoftは特許などの権利を主張することはな」いんだそうです。

・・・Winformsは入ってませんけど。まあ。

最近、MSの動きが速くなったような？

IronPythonの、というかSharpDevelop 3.1ベータのハウを知る

Sharp Develop 3.1ベータを使って、IronPythonでGUIアプリを書く実験をしてます。

（IronPythonStudioだとUIをXAMLで記述することになるのですが、少し大げさすぎる気がするので。）

で、ちょっと気づいたこと。

●GUIデザイナで生成されたコードをいじらない方法

GUIデザイナ（というかデザインタブというか）でフォームにボタンやらラベルやらをぺたぺたと貼り付けるとUIのコードが生成されるのですが、

イベントハンドラ（というかボタンが押されたときに呼び出されるメソッド）の中身は、初期状態でpassになっていて、それを書き換えろと言わんばかりになっています。

もちろん書き換えたあとで、GUIデザイナを使ってボタンを足したり、とかは問題なくできるのですが、やっぱりなんとなーく気持ち悪い。

生成されたコードをいじらないで何とかならないか？ということで試行錯誤。

結果、成功した方法は、MainFormを継承したクラスを作るというもの。

(1) 生成されたクラスのMainFormはそのままにしておいて、MainFormを継承したクラスを作ってMyMainFormとする。

(2) MainFormのイベントハンドラ（であるメソッド）の中身を書き換える代わりに、MyMainFormでイベントハンドラのメソッドをオーバーライドする。

(3) エントリポイントとなるProgram.pyでMainFormを使っているところはMyMainFormに書き換える。（あるいは、Program.pyを書き換えるのがイヤならMyProgram.pyを作るのもアリです）

●アバウトダイアログをGUIデザイナで作りたい

どうも、GUIデザイナで触れるクラスはMainFormのみらしく、後からダイアログのクラスを付け足してGUIデザイナで作る、とかはできないらしい。

では、アバウトダイアログはガリガリ手書きするのか？いくらなんでもそりゃないでしょ、ということで。

試行錯誤した末、アバウトダイアログのためにひとつプロジェクトを作ってやる方法でうまくいきました。

(1) アバウトダイアログを付け足したいアプリのソリューションを右クリックして、新しいプロジェクトを作る・・・

(2) このとき、新しいプロジェクトのディレクトリが、元のアプリの子ディレクトリになるようにする。

たとえば、元のアプリがc:￥MySolution￥MyAppだったら、新しいプロジェクトはc:￥MySolution￥MyApp￥AboutDialogとかにする。

(3) 新しいプロジェクトを元のアプリのプロジェクトからインポートできるようにする。c:￥MySolution￥MyApp￥AboutDialogに__init__.pyを作る。

中身は、「from MainForm import MainForm」1行のみ。

これにより、新しいプロジェクトのMainForm.pyというファイルで定義されているMainFormというクラスを、元アプリからAboutDialog.MainFormという名前でアクセスできるようになる。

(4) 新しいプロジェクトのMainFormをGUIデザイナでアバウトダイアログとして設計する。

copyrightを書いたり、OKボタンを付けたり。

(5) 元アプリのメニューに「about」を作ってやり、そのイベントハンドラ（であるメソッド）の中身を

import AboutDialog
AboutDialog.MainForm().Show()

とする。

IronPythonでマルチプラットフォームGUIの可能性 番外編

記事「R.Stallman氏、「MonoやC#への依存を減らそう」と呼びかけ」
http://sourceforge.jp/magazine/09/06/29/050217
より。

「Stallman氏はその理由として、米Microsoftが将来的に、ソフトウェア特許を使うことでMonoなどあらゆるフリーのC#実装に対し脅威になる可能性がある」

まあ、この辺は言いたいこと分かるというか。2007年の例もありますし。

むしろ、Mono開発者の↑への反論

Apebox.orgの記事「Here we go again – why Mono doesn’t suck」
http://www2.apebox.org/wordpress/rants/124/
より。

「System.Windows.Forms are not included by default, and are rarely used in Free applications anyway (because WinForms looks like ass, amongst other things)」

にちょっとへこみました。

System.Windows.Formsってそんなにひどいかなあ。GTKとかと流儀が違うっていうのは分かるけど。

メモ: JStyle, spidermonkey-bin

調べごとをしているうちに、何となくアンテナに引っかかったツールたち。

(1) JStyle

Eclipseで等幅！改行文字もきれいに表示。
名前だけから、Janeなんたらと勘違いして尻込みしてました。
某大掲示板から。

開発元
http://mergedoc.sourceforge.jp/

(2) spidermonkey-bin

Javascriptのインタラクティブシェル。
微妙に便利。

高林哲さんの「SpiderMonkey で JavaScript のインタラクティブシェル」より。
http://0xcc.net/blog/archives/000048.html

(2009/07/01)
「等幅」とすべきところを「同幅」になっていたので修正。
ついでに「等幅」の読み方が「とうはば」なのを知りました。
いままでずーっと、「とうふく」だと思っていたので。

IronPythonでマルチプラットフォームGUIの可能性 #2

(#1 から続く）

マルチプラットフォームのためには、この便利なやつ、winforms.pyはあきらめるしかないのでしょうか？

それはちょっとなあ、ということで試行錯誤。

結局、

winforms.pyの1つ目の利点は使うが、2つ目の利点は使わない

というところで妥協することにしました。

具体的には、

(1) Windowsマシン上で開発し、winforms.pyを使って対話モードでGUIを作る。

(2) ただし、最終的なコードではwinforms.pyを取り除けるようにするため、winforms.*といった名前を使わない。

あるいは、(2)の代案として、

(2') 最終的なコードがUbuntuでも実行できるようにするため、パッケージ名のショートカットの部分だけを提供するような偽winforms.pyを用意する。

という風にすれば良さそう（少なくとも小さなサンプルを2, 3試した限りでは）。

実際には、Monoと.Netとでは機能の有無以外にも「ちょっとした」振る舞いの違いとかがありそうなので、コードがUbuntuでも動作するかどうか、開発中はこまめにチェックする必要があると思います、と但し書きを付けておきます。

ちなみに。

いろいろやってるうちに気がついたのですが、（PYTHONPATHのIronPython版である）環境変数IRONPYTHONPATHでは、パス区切り文字が「￥」ではなく「/」とするらしい。

IronPythonのチュートリアルのディレクトリに入っているwinforms.pyにパスを通すには、

set IRONPYTHONPATH=C:/Program Files/IronPython 2.0.1/Tutorial

となります。違和感ある。

IronPythonでマルチプラットフォームGUIの可能性 #1

ちょっと時間を取って、IronPythonでいわゆるWinformsを使うGUIを試してみます。Windowsで動くのは当然として、できれば、Ubuntuでも動いてくれるとうれしい。

Ubuntu 9.04のMonoは2.0、要は.Net Framework 2.0相当なので、このバージョンの機能ならおそらく動いてくれるはずです。

いろいろやって気がついたのは、IronPythonの配布ファイルに含まれている、winforms.pyはMonoでは動かないこと。

これは惜しい。このwinforms.pyは2つの意味で便利なので。

1つ目は、winfoms.pyをインポートすることにより、対話モードでGUIを試すことができます。

IronPythonのシェルから、対話的にフォームを作って、ボタンを貼り付けて、テキストや色を変えて、と、いろいろ実験するにはうってつけです。

2つ目は、winforms.pyはパッケージ名のいわばショートカットを提供すること。

本来は、System.Windows.Forms.FormとかSystem.Drawing.Pointみたいに別個のパッケージに分かれているのを、winforms.Form, winforms.Pointといった名前で使うことができます。

Monoでwinforms.pyが動かない原因は、winforms.pyがスレッドを裏で作ってメッセージポンプ（今はそんな言い方しないかも）を回す、という機能が、Monoでは提供されていないコンポーネントで実現されていることでした。コードを見る限り、Monoで動くwinforms.pyの代替品を用意することは難しそうです。

マルチプラットフォームのためには、この便利なやつ、winforms.pyはあきらめるしかないのでしょうか？

（続く）

boolはintだった

Pythonを使っていて、

if isinstance(item, int):
　ほげほげ
elif isinstance(item, bool):
　ふがふが

というコードを書いてハマりました。

itemがTrueのとき、「ふがふが」のところを通りません。

デバッガで追いかけてやっと、isinstance(True, int)が真になるからだと分かりました。

何故か？それはboolはintのサブクラスだから。

以下はPython 2.6では全部成立します。

isinstance(True, int) == True
isinstance(False, int) == True
issubclass(bool, int) == True
1 == True
0 == False

もうだいぶ使っているのですが、ちーとも気づいていませんでした。

あー、バッドノウハウっぽい。

Python json: 不思議。

jsonパッケージをちょっと試してみようと思って、疑問が。

自前で定義したクラスのオブジェクトをシリアライズ（要はjsonの表現に変換）したいですが、

いくつかサンプルを当たってみると、

どうやら、シリアライズするときはヘルパクラスを用意して、復元（デシリアライズ）するときはヘルパ関数を用意するらしい。

なぜ非対称になってるんでしょうか？

不思議。

Original Sin、て分かってたことなのに

記事「"Original Sin" (Would Java be Better Off Without Primitives?)」
http://www.infoq.com/news/2009/06/java-without-primitives

（日本語訳
http://www.infoq.com/jp/news/2009/06/java-without-primitives
）

より。

プリミティブ型を排してすべてをオブジェクトにすべきだ、というもの。

そうすれば、「charが16ビットであるために、最初は文字だったのが、エンコードされたコードポイントを扱わなくならなくなった」といったような事態をさけることができたはず、という議論です。

言いたいことはわかるけど、ほんとの原因はそこかなあ？という感想。

Write once, run anywhereなどというスローガンのために、intのビット数とか、桁あふれしたときの丸め方とかまで仕様として決める必要があったわけで（記憶によると）。それがなかったら、Javaが今のように普及してたかどうか。

特に、charに関して言えば、当時から日本では16ビットの文字集合に非難ごうごうだったわけで、馬耳東風で採用した段階でこうなるのは見えてたわけだし。

個人的には、言語のプリミティブを変更できるほど、コミュニティに体力（気力）が残ってるのかなあ、というのも疑問です。