この記事は動的言語用の IDE についてのシリーズの一部となっている。同シリーズのほかの記事は DynamicLanguageIDEs タグ(参考記事リンク)を通じて見つけることができる。
ほとんどの動的言語用 IDE はおなじ困難を共有しているため、他の言語がその困難にどのように対処しているか知ることは興味深いことではないかと思う。なので、今回は Ruby ではなく、しかし Ruby とさほど違わない言語である Python を取り上げてみたい。
Aptana Pydev
Aptana は IDE マーケットにおける地位を日増しに強めている。RadRails の開発を、その開発者である Matt Kent 氏と Kyle Shank 氏から引き継いだあと(参考記事・英語)、Aptana は Eclipse ベースの Python 用 IDE である Pydev のメイン開発者である Fabio Zadrozny 氏も雇い入れた(リンク)。
Python と Jython の IDE として高い評価を得ている Pydev が Aptana の製品ファミリに加わった。そして、Pydev の開発者である Fabio Zadronzy 氏は今後も Aptana チームの一員として Pydev の発展にむけた活動を率いてくれる。このように発表できることを、私たちはとてもうれしく思っている。
わたしたちは Pydev の現状と未来について Fabio 氏にインタビューし、Pydev が他の IDE と異なる点について尋ねた。
もしかすると少しひいき目に見ているかもしれないが、コード補完のようなコードインテリジェンス機能がとてもすぐれていると考えている。Pydev エクステンションを使うなら、そのコード解析機能は、python プログラマがそれなしでは生きていけなくなるほどの出来だ（そしてもちろん、デバッグ機能や新しく導入されたインタラクティブコンソール、定義の検索、エディタ機能などもある）。Eclipse のエコシステムを利用できることも助けとなっている。ユーザは Subversive や Mylyn といった多くの他プロジェクトの成果から利益を得ることができるからだ。
現在 Pydev は Aptana 製品となったわけだが、ユーザにとって何か変化はあるか？ そして Aptana の他の製品には興味をもたない人たちにとって、Pydev は今後もスタンドアロンの IDE として利用可能な製品でありつづけるのか？
Pydev は、Aptana 製品となったことで、今後もこれまでと同等の品質、同等のサポートを維持しながら成長をつづけていけると考えている。Pydev のユーザ数は増え続けているし、ひとりでこの製品をメンテナンスすることがどんどん難しくなってきているからだ（他の開発者もときどきはメンテナンスに貢献してくれているが、これまで、製品の安定性を高めるために開発やサポートをしてくれた人はいない）。
ふたつ目の問いに対する答えは、イエス。今後もスタンドアロンの Python 専用 IDE として利用できるし、Aptana Studio の一部としてでなくても動作する。
Pydev は、Jython から派生し Python の新しいバージョン用に改良を加えた独自のパーサを使っている。現在、Jython 2.5 は ANTLR ベースの新しいパーサを使っているが、(リンク)これを Pydev に移植する予定などはあるか？
特にない。Pydev のパーサは Jython のそれよりもたくさんの情報を必要とするし（リファクタリングのためだ）、コードは実は分岐してしまっている（そして、必要とされる情報を提供するために、分岐したコード上でかなりの作業が発生している）。また、速度面でいうと、分析の結果、Pydev パーサは Jython パーサよりもさらに高速であることが判明している（よりたくさんの情報を提供するのにもかかわらず。そして解析速度は Pydev にとって非常に重要だ）。
今後 Pydev にどのような機能の追加を予定しているか？
普段、わたしは開発する機能を前もって予定していない。新機能を追加する時機がくれば、機能に対する要求をチェックし、より有用だと思われるもの（そして要求の多いもの）を選び出そうと思う。現在は、Eclipse 3.2 ～ 3.4 に対応するための作業中だ（これまでに実装済の機能すべてがきちんと動作するように配慮している）。
Pydev の興味深い機能はリファクタリングのサポートだ。わたしたちは、タームプロジェクト (リンク).でリファクタリング機能の大部分を実装し拡張した Robin Stocker 氏と Reto Schüttel 氏にインタビューした。
あなたたちが提供しているリファクタリング機能とはどのようなものか？
わたしたちは以下のリファクタリング機能およびジェネレータを実装した。
- Docstring の生成
- ローカル変数のインライン化
- ローカル変数の抽出
- ローカル変数のリネーム
- メソッドのリネーム
- 属性のリネーム
- クラスのリネーム
これがどのようにすぐれているのか？ 検索や置換を行えばすむのではないか？
検索や置換を使うこともできるが、その場合、検索結果をひとつひとつ確認してリネームを行うかどうか決めなくてはならない。それに、たくさんのファイルを検索したり置換したりするのはとても面倒だ。
たとえばあなたが「Puzzle」クラスの「solve」メソッドをリネームしたいとしよう。その場合あなたは、「solver」という変数をリネームしたくはないだろうし、「Solver」クラスの「solve」メソッドもリネームしたくないだろう。
わたしたちの実装したリネーム機能はとても頭がいい。コードを読み、それを理解しようとし、その上で、ある識別子のリネームが必要かどうかを判断する。「solver」という変数や「Solver」クラスの「solve」メソッド呼出は「solve」メソッドとは無関係で、それゆえリネームの必要がないということを理解してくれる。
このように知的な決定を行わせるために、わたしたちは Python のための型推論システムを実装した。このシステムは DLTK のひとたちが Ruby IDE で利用しているものと同じアルゴリズムに基づいている。
新しいリファクタリング機能のほとんどは Pydev に取り入れられている。今後はどのような予定があるのか？
現在継続中のプロジェクトで、わたしたちは型推論エンジンを抽出し、それを他の目的にも利用できるように(リンク)拡張および改良する独立したプロジェクトとした。
次のステップでは、改善された型推論エンジンを Pydev と再統合し、リファクタリング機能がその改善の恩恵を受けられるようにする。ただ、わたしたちは二人とも別作業に追われているので、いつそこに到達できるかは見えてない。
Pydev に関してもっと知りたい方は Pydev のウェブサイト(リンク)か、Aptana に新しく作られた Pydev のページを参照してほしい(リンク)。
DLTK Python
DLTK も Python(リンク) をサポートしているが、こちらはまだ孵化状態にある。プロジェクトリードの Andrey Platov はその意味について次のように説明する。
Python 界隈にはアクティブな開発者がいないということだ。DLTK Python のレベルは Ruby のレベルには遠く及ばないし、「孵化状態」という言葉は要するに「これはまだ開発中なので、今すぐに利用できる IDE だとは思わないでくれ」ということだ。
[...] Python コンポーネントが Ruby や TCL と同じ水準であったならすばらしいことだ。しかし、わたしたちにはそれを実現するだけのリソースがない。最初のころは、コンセプトの実証を行うということを念頭においていたが、今では DLTK 上に実装された別の言語が十分に存在するし、Python IDE がシームレスに DLTK インフラにフィットするだろうということをわたしは疑っていない。
この記事は動的言語用 IDE に関する現在進行中のシリーズの一部となっている。同シリーズのほかの記事は、InfoQ の DynamicLanguageIDEs タグ(参考記事リンク)から探すことができる。