魅力的な Python: JPython と Python for .NET の内幕

作成者とのインタビュー

David Mertz が、JPython および Python for .NET の開発者である Mark Hammond、Finn Bock、および Barry Warsaw にインタビューしました。David は Mark から Microsoft 開発の内情を少し聞き出し (もちろん、彼が締結している機密保持契約の範囲内でのことです)、JPython や彼らの今後の Jython プロジェクトについて、Finn と Barry 鋭く迫りました。

David Mertz, Ph.D, Author, Gnosis Software, Inc.

Photo of David MertzDavid Mertz 氏は多くの分野で活躍しています。ソフトウェア開発や、それについて著述もしています。その他、学術政策理念について分野を問わず、関係する雑誌に記事も書いています。かなり以前には、超限集合論、ロジック、モデル理論などを研究していました。その後、労働組合組織者として活動していました。そして、David Mertz 氏自身は人生の半ばにもまだ達していないと思っているので、これから何かほかの仕事をするかもしれません。



2000年 12月 01日

Python は一般に CPython と同一視されていますが、その仕様は、Java や .NET 用のアプリケーションを含む他の個所で、何回か実装されています。JPython は Python ソースを Java バイトコードにコンパイルし、Java クラスに透過的にアクセスできるようにします。Python for .NET は、Microsoft の来たるべき言語間テクノロジー・プラットフォーム用の、完成途上のアプリケーションです。私は、Mark Hammond、Finn Bock、および Barry Warsaw とのインタビューで、なぜ JPython および Python for .NET が開発されたのか、またこれらの代替 Python 実装にこれからどのようなことが起こるのかについて、知識を深めることができました。

Python for .NET

Mark Hammond は、すばらしい PythonWin 環境の開発および PythonCOM の拡張により、ほとんどの Python プログラマーにおなじみになっています。また、私たちが Mark を仰ぎ見るのと同じ理由で、Microsoft も Mark を高く評価しています。Microsoft は、Python for .NET の実装について援助を求めるため、彼に連絡を取りました。Mark によると、Python for .NET の稼動バージョンは間もなく使用可能になるはずであり、すでにアルファ版またはベータ版を ActiveState から入手できるはずだそうです (参考文献を参照)。

David Mertz: Python for .NET とは、いったいどういうものなのですか?特に興味深いのは、すでに Windows の内部を制御できるようになっていると思われる、あなた自身による CPython への PythonWin および PythonCOM 拡張と、Python for .NET がどのように関連しているのかということです。

Mark Hammond: Python for .NET は、Microsoft .NET プラットフォームに Python を実装する、コンパイラーでありランタイムです。.NET プラットフォームに備わっているランタイムおよびメタデータ・システムは、完全な言語インターオペラビリティーを可能にするように設計されていますが、それを実現するためには、それらの言語がそのランタイムで機能する必要があります。

たとえば、ある Python クラスを public に設定して、Visual Basic プログラマーがそこから継承を行えるようにする場合、その Python クラスは、CPython 用語ではなく .NET 用語で実装され、記述されている必要があります。

Python .NET の優れている点を簡単に言うと、.NET フレームワークと相互操作できることです。実装が未熟であるなどの理由により、まだ弱点がたくさんあります。しかし、これは時間の問題にすぎません。開発や微調整に関しては、まだベータ段階なのです。

Mertz: 現時点での Python for .NET と CPython との間の非互換性については、どのようにお考えですか?

Hammond: ほとんどのモジュールがまだ実装されていないため、C で書かれた既存のモジュールは、絶対に使用できません。.NET フレームワークで使用するのでなければ、現時点で Python .NET を使用する必要はないように思います。

Mertz: 言語間通信や複数言語アプリケーション開発のしやすさなど、Python for .NET にはいくつかの大きな利点があることは確かです。しかし、Python+C+SWIG などのような、現在出回っている製品よりも優れていると言えるとすると (もちろんこれは、仮定の話ですが)、それはどういう理由によるのですか?

Hammond: そうですね、Python+C+SWIG との比較では、はっきりしています。言語間呼び出しが Python+C+SWIG の場合のように難しくなることはないはずです。しかし、SWIG は、その他の多くの点で、すばらしい製品です。Python C 拡張機能の作成を黒魔術の世界から引きずり出して、ほとんど難しくないレベルにまで持ってきたのですから。

.NET は COM や Corba と比較するほうが適切でしょう。COM も Corba も、ともに、手作業やコンパイルをしないで言語間呼び出しを「機能させる」ことのできるソリューションを提供します。.NET はこの一歩をさらに進め、言語間継承や例外機能などを備えるようにしました。このような利点は、Java 仮想マシンで行われる複数言語実装とよく似ています。

Mertz: Python for .NET は Python スクリプトを外部仮想マシンの形式にコンパイルします。.NET VM が Stackless や Vyper の風変わりな機能のいくつか、たとえば、継続、ジェネレーター、コルーチン、末尾再帰、緩やかな評価などをサポートするようになるかどうか、予測していますか?

Hammond: はい、理論的にはそうなるでしょう。しかし Microsoft ベータ同意書によって、パフォーマンスについてはお話できない約束になっています。中核的な Python 言語解説書で定義された機能についてだけお話することにしましょう。ガーベッジ・コレクションは、JPython や JVM の場合と同じように固有のものです。

Mertz: 政略の話題に話を移しますが、Microsoft が Python for .NET の開発を進めているのはなぜだと思いますか?

Hammond: .NET フレームワークをターゲットとして選択した人が Python を使用できるようにするためです。Microsoft は早い時期から、彼らの VM を本当の意味で言語に縛られないものにするために、Python やその他の多くの言語に取り組むことを決断しました。現在彼らは、多くの言語実装者からのフィードバックに基づいて、自分たちの VM にいくつも変更を加えています。

Mertz: 彼らと Python for .NET の財務関係はどのようになっているのですか?あなた方が出資しているのですか?彼らがあなた方に出資しているのですか?

Hammond: Greg Stein と私は Microsoft との間で Python for .NET を作成する契約を結んでいます。その契約の条項は機密になっています。しかし、私は基本的に (Perl for .NET 実装を担当した) ActiveState のために作業をしています。私は、彼らもいつかは、移植を完了させるために Microsoft と同じような契約を結ぶと予想しています。

Mertz: Python for .NET のライセンスとの関係で、これはどのような意味をもちますか?

Hammond: Python for .NET のライセンスには "(c) Microsoft" という注記が付くことになるでしょうが、まったく自由に使用できるはずです。

Mertz: Microsoft が、おなじみの「囲い込み、拡張、制圧」戦略の一環として、所有権を主張できる拡張や機能強化を使用するのではないか、という懸念がどうしてもぬぐえません。つまり、長期的に見た場合、Python for .NET が実際には Python にとってあまりプラスにならないのではないかと心配しています。

Hammond: もしも .NET が有効な勢力に育ったとしたら、それをターゲットとした Python 実装を備えていてこそ Python のためになります。JPython が JVM をターゲットとすることによって Python のためになっているのと、よく似ています。


JPython

Barry Warsaw と Finn Bock の 2 人は、現在最も活発な JPython 開発者です。もっとも、JPython は、きわめてコミュニティー指向のやり方をしています。残念なことに、もともとの JPython 開発者である Jim Hugunin は、JPython に積極的に関与できなくなってしまいました。このインタビューの省略されていない (したがってまた、より技術的な) バージョンが、私の Web サイトに記載されています (参考文献を参照)。

David Mertz: JPython とは、どういうものなのですか?

Barry Warsaw: 私がいつも使っている営業用スピーチをしましょう。

JPython は、Python プログラム言語を 100% Pure Java で実装したものです。これを使用することにより、ユーザーは Python ソース・コードをコンパイルして Java バイトコードを作り、それによって得られたバイトコードを任意の Java 仮想マシンで実行することができます。Java とは、きわめてシームレスかつ円滑に統合されています。Python からは、すべての Java ライブラリーにアクセスし、アプレットを組み立て、Java bean と統合し、また Java クラスを Python のサブクラスにしたり、Python クラスを Java のサブクラスにしたりすることができます。Python と同じように、また Java とは異なり、JPython は対話式に使用することができます。プロンプトでいくつかの JPython コードを入力するだけで、すぐに結果を見ることができます。

もっと簡単な言い方をすると、こうなります。JPython を使用することにより、必要に応じてどのような Java コードでも書くことができ、しかもそのコードを変換すると、2 分の 1 から 10 分の 1 までの行数のコードになります。Python は動的に型が決まる言語であるため、アプリケーション開発を非常に速く、きわめて少ないバグで行い、とても柔軟なプログラムを作成することができます。

Mertz: JPython の開発はどのようにして始められたのですか?

Warsaw: JPython は Jim Hugunin によって考案されました。彼は今、Xerox PARC で Aspect Oriented Programming プロジェクトの仕事をしています。私は Jim をよく知っていますので、彼はきっと難しい課題に興味を持ったのだろうと考えています。Python の世界の多くの人々は、それが可能だとは考えていませんでした。Guido 自身、懐疑派の一人でした。しかし Jim は、彼らが誤っていたことを証明したのです。

それでは、課題がかなえられた今、なぜ JPython 開発を続けるのでしょうか?それは、JPython が、ほとんどの Java プログラマーに知られることのない、最も価値ある Java ツールだからです。今でも。

Mertz: JPython への要求に拍車をかけたのは何だと思いますか?

Warsaw: まず初めに、JPython が Java のライバルではないということを理解していただく必要があります。Java は静的に型が決まる、コンパイル型言語です。これにより、ライブラリーの型安全性と、高速な実行速度が保証されます。おもしろいことに、Java がバイトコード解釈型であるにもかかわらず、ほとんどの人が Java を従来からの作成・コンパイル・実行・編集型のプログラムであると考えています。そしてもちろん、Java は広大なソフトウェア資産を活用していますので、Java プログラマーは多くのリソースを使用することができます。

しかし同じ静的型決定の従来型のプログラミング・サイクルでは、人的リソースの点で Java アプリケーション開発のコストが増大しています。そしてこの点では、Python が絶対に優れています。Python は大変単純で小さな言語であるため、学習が簡単です。ほとんどの熟練プログラマーは、1 日程度で十分な実用レベルまで Python を習得することができます。また Python は、コードが書かれるよりも読まれることが多い点に着目して設計されています。ですから Python のソース・コードは、大規模なチーム・プロジェクトで共用しやすくなります。

しかし、それよりも重要なことは、Python が非常に高水準の、動的に型が決まる言語であることです。言い換えれば、タスクの実行に必要なコードの量が大幅に節約できるのです。Python を使用すると、書くコードの行数が少なくなるので、短時間で、しかも少ないバグでコードを書くことができます。これは、速くアプリケーションを開発するためにはすばらしいことです。

Python は対話式インタープリターも備えていますので、インタープリターのプロンプトに従い、Java コードをインポートし、Java クラス・インスタンスを作成し、メソッド呼び出しを行うなどのことが、すべて対話式で行えるのです。これは、会社の Java ライブラリーの使い方についてプログラマーを訓練したり、新しい Java API を経験したりするための、すばらしいツールです。

私の考えでは、すべてのプログラマーは CPython と JPython の両方を手持ちの武器に加えるべきです。

Mertz: CPython と比較した場合の JPython の利点はどのようなことですか?

Bock: JPython を使用すると、その基礎にある実装言語に完全にアクセスすることができます。ほとんどの (おそらくすべての) C ベースのスクリプト言語では、C 関数を、その C 関数をスクリプト言語に開示するためのシン・レイヤーのコードでラップする必要があり、このラッパー・コードの作成を自動化するために SWIG などのすばらしいツールが存在しています。しかし JPython では、まず第一に、ラッパーが不要です。書かれた Java コードはすべて、そのまま JPython で使用可能になり、この統合は大きな効果をもたらします。JPython で定義されているクラスおよびインスタンスは、通常の Java のクラスやインスタンスのように Java コードに渡すことができます (Java のクラスやインスタンスそのものなのですから)。

埋め込み/拡張 API により、アプリケーションやモジュールから、きわめて洗練された形で JPython オブジェクトにアクセスできるようになります。この洗練性は、ある部分は、JPython と Java がともにオブジェクト指向の言語であるという事実によるものです。Jim は、このことを大いに利用したのです。

Warsaw: CPython に欠けているのは、世の中に出回っている膨大な量の Java コードへのアクセスです。使用したい Java ライブラリーがある場合には、JPython のほうを選ぶべきです。もちろんそれと引き換えに、JPython は世の中にある既存の C ライブラリーに簡単にアクセスすることができません。Finn は、JNI を介して Tkinter などを POSIX モジュールと統合しましたが、100% Pure Java の認証を保持したい私たちにとって、Tkinter などは JPython では常に非標準となります。

Mertz: それでは、JPython の弱点についてはどのようにお考えですか?

Finn Bock: JPython は Java コードだけにアクセスするもので、既存の C モジュールへのアクセスはできません。ですから、C で実装された各 Python モジュールは、Java で実装し直さなければなりません。それに、CPython には非常に多くのモジュールがあります。

また、ソース・コード以外の埋め込み/拡張 API に関する文書がほとんどありません。

Mertz: 純粋な Java と比較した場合、JPython には何か利点がありますか?

Warsaw: 純粋な Java の機能はほとんど網羅できていると思います。しかし、JPython のパフォーマンスの問題についてはお話しておきたいと思います。JPython は Python の動的セマンティクスを実装しているため、JPython にはかなり多くのランタイムが付きものになっています。アプリケーションによっては、これがパフォーマンスに悪影響を与える可能性があります。これらは、ジャストインタイム・コンパイラーや Hotspot テクノロジーなどの標準的な Java の最適化により、かなり緩和できます (8 か月前のベンチマーク・テストでは、JIT 対応の JVM である JPython 1.1 は、CPython 1.5.2 の速度にかなり迫る場合があり、ときにはそれを上回ることもありました)。これらのベンチマーク結果を更新し、JPython の後継版を送り出した後はパフォーマンスの問題に専念する予定です (詳細については、下記を参照)。

しかし CPython と同じように、Java では、アプリケーションのうちのパフォーマンスが重要なセクションをいつでも書き換えることができます。

Mertz: JPython はどの程度広く使用されると思いますか?

Warsaw: ますます広く使われるようになりつつあると思います。技術的な成功のためにこれが重要であることが、分かってもらえるようになってきました。JPython は、エンド・ユーザーが利用できるスクリプト記述環境の提供から、Java ライブラリーおよびアプリケーションのテスト用フレームワークを作りやすくすることまで、あらゆる種類のタスクに役立ちます。JPython の現時点での最大の弱点は、より多くの宣伝広告が必要なことです。私は、この記事が広報部門の助けになることを期待しています。

Mertz: JPython は CPython に追い付けると思いますか?

Bock: はい。JPython は、今にも追いつこうとしています。新しい機能は、ほとんどすべて、先に CPython のほうに追加されます。(しかし、ストリング・メソッドが追加されたのは JPython のほうが CPython よりも先でした。) JPython はこの点で不利になっています。それは、中核的な開発者が、CPython には JPython の 15 倍もいるからです。しかしそれでも、JPython バージョンには、CPython 2.0 に含まれるほとんどすべての新規機能を組み込む必要があります。

私としては、実際にはまずまず同程度になっていると思います。現実の世界では、一方が他方よりもやや勝ってはいますが。

Warsaw: 私は、言語レベルでは JPython と CPython は完全な互換性を備えるべきだと、固く信じています。これが不可能である場合、Guido は、その相違点が実装に依存するものであるのか、いくつかの実装にバグがあるのかを見きわめます。CPython と JPython がいつかは同格になり、JPython がある部分で CPython 開発を引っ張り、それと同程度に CPython が JPython を引っ張るようになればよいと思います。

現在でも、Unicode サポートでは、そのようになっています。JPython はすでに、すべて Unicode になっています。そのほかの例として、型/クラスの二分法があります。CPython には、ストリング、ディクショナリー、リスト、数値などの組み込み型があります。クラスやインスタンスもあります。組み込み型からは継承ができません。さらに紛らわしいことに、インスタンスには型とクラスの両方が備わっています。JPython はオブジェクト指向の実装であるため、こうした欠陥の修正は JPython から先に取りかかったほうが楽かもしれません。

Mertz: JPython と CPython との間には、どのような非互換性があるとお考えですか?

Warsaw: 両者の機能には、小さな違いがたくさんあります。それについてはすべて、JPython の文書で概略が示されています。やはり、そのうちのいくつかは特定の言語定義が行われていれば許容可能な相違として分類され、また、なんらかの実装を修正すべき場合が指摘されていることもあります。ほとんどは、ごく小さな違いです。

Bock: モジュールの中に、JPython では実装されていないものや実装できないものがあります。また、いくつかのモジュールは JNI モジュールとしてでなければ実装できないため、配置環境では役に立たない可能性があります。

Bock: 実際に私が自分の書いたスクリプトやプログラムを (IDLE、PySol、および PMW ツールキットとともに) 移植したときに発生した問題は、ガーベッジ・コレクションのランダム再利用や_del_メソッドの欠落などではありませんでした。これまでほかの誰も体験しなかった、CPython の振る舞いのような小さな問題でした。

Warsaw: JPython の次期バージョンは Python 2.0 言語定義と互換になりますので、最大の捕り物はライブラリーで行われるようになるでしょう。CPython ディストリビューションの標準ライブラリー・モジュールのうち、純粋な Python で書かれたものは、移植可能になるはずです。C 拡張モジュールは、特別に JNI ブリッジを介して組み込んだり Java で実装し直したりしないかぎり、移植可能にはならないでしょう。また、Java API を排他的に使用する JPython アプリケーションを CPython に移植して戻すのは、大変だと思います。

その一方で、2 つのシステムのライブラリーには、多くの共通した機能が含まれています。十分な見通しを立てれば、アプリケーションに互換性レイヤーを組み込むことができます。

Mertz: JPython の将来の方向性について、何かお考えがありますか?

Warsaw: 私たちは、公的な JPython 1.1 リリースに基づいて、"Jython" という JPython の後継バージョンをすでに作成しています。これは、プロジェクトの長寿性と安定性を確保するためのことです。この作業は、すべて CNRI の JPython 1.1.x ライセンスに従って行われました。私たちはすでに開発プロセス全体を SourceForge に移していて、CPython でうまくいっているものと同じようなオープン・プロセスを使用して管理する予定でいます。Finn と私は、確かに Jython の将来の開発に深くかかわっています。Jython は、OSI で認証された CPython 2.0 ライセンスによってリリースされる予定です。これはほとんど「公式」に近い選択肢ですので、現在の JPython コミュニティーは、Jython が立ち消えになることはないと信じてよいでしょう。私たちは、かれらがいつかは全員 Jython に移行することを希望しています。

現在、コードはまだアルファ段階ですが、Finn と私は Jython 2.0 リリースのためのいくつかの技術的な重要事項に取り組んでいます。すでに Finn によってエラー訂正表が作られています。CPython 2.0 には、割り当ての増加や拡張印刷などの機能が備わっています (リスト包括もまもなく組み込まれます)。フリーApache Jakarta OROMatcher コードも組み込んでありますので、二重ライセンス取得の必要がなくなります。また、多くのバグ・フィックスも行われています。Jython 2.0 の最初のアルファ版がいつリリースされるかは分かりませんが、すべてのコードは現在 SourceForge CVS ツリーで使用可能になっています。

参考文献

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Linux
ArticleID=228560
ArticleTitle=魅力的な Python: JPython と Python for .NET の内幕
publish-date=12012000