レベル: 初級 David Mertz, Ph.D (mertz@gnosis.cx), Author, Gnosis Software, Inc.
2000年 12月 01日 David Mertzが、JPythonおよびPython for .NETの開発者であるMark Hammond、Finn Bock、およびBarry Warsawにインタビューしました。DavidはMarkからMicrosoft開発の内情を少し聞き出し (もちろん、彼が締結している機密保持契約の範囲内でのことです)、JPythonや彼らの今後のJythonプロジェクトについて、FinnとBarry鋭く迫りました。
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ツリーで使用可能になっています。
参考文献
著者について  | 
| | David Mertz氏は多くの分野で活躍しています。ソフトウェア開発や、それについて著述もしています。その他、学術政策理念について分野を問わず、関係する雑誌に記事も書いています。かなり以前には、超限集合論、ロジック、モデル理論などを研究していました。その後、労働組合組織者として活動していました。そして、David Mertz氏自身は人生の半ばにもまだ達していないと思っているので、これから何かほかの仕事をするかもしれません。 |
記事の評価
| 
