dseg 曰く、
昨年は/.-Jにもインタビューセクションが創設され、本家のインタビュー記事が多数翻訳・掲載された。
その中には、Perlの作者であるラリー・ウォール氏へのインタビューや、Rubyの作者であるまつもとゆきひろ氏へのインタビューも含まれており、
言語の生い立ちから設計者の思想まで興味深く読めたのではないだろうか。
そこで今回は、本家/.の過去ログ倉庫にひっそりと収まっていた、Pythonの作者・Guido van Rossum氏へのインタビューの翻訳記事を、
言語繋がりという事もありお届けしたいと思う。
Pythonは海外での人気が先行したオブジェクト指向スクリプト言語。
キラーアプリケーションのZopeの登場などもあり、近年その普及度・重要度は増すばかりだ。
本家/.での掲載が2001年春の記事であり、内容的に多少賞味期限が過ぎている感は否めないが、
言語の設計思想やPythonの未来について語った部分は未だ変化しておらず、興味深い内容となっている。
尚、本翻訳記事は/.-Jの日記において、有志諸氏による共同作業の結果として完成した。
訳文を頂いた以下の皆さんに深く深く感謝します:
Max氏、hayami氏、Jadawin氏、k3c氏、WindVoice氏、AC氏。
謝辞と各氏の担当された章のリストは別記にて。
1) Ruby
by Luke
――Rubyについてどう思いますか?
Guido van Rossum(以下 グイド):
ちょっと見た程度で、使ったことはないんだ。Parrot(※訳注1)みたいに、PythonとPerlを合わせたような感じに思える。
エイプリルフールのジョークのようにおもしろい(※訳注2)が、
私のプログラム言語に対する感性をうまくくすぐるようなモノではないね。
もちろん、良くできた言語じゃないかと思う。日本じゃすごく人気があるみたいだし。特にどうこう思う事はないよ(※訳注3)。
訳注1: Parrot
2001年のエイプリルフールに用意された「ネタ」言語。
Perl作者のラリー・ウォール氏とグイド氏が共同で取り組む新言語、と発表され、O'Reillyのページに詳細な記事が載る程の仕込み様だったため、
ニュースサイトを中心に被害者が続出した。
尚、現在 Parrot と言えば、parrotcode.org で開発されている Perl6 のコアを指す。結局、この「ジョーク事件」から名前がとられた。Parrot は Perl6 などのインタプリタ言語をバイトコード化し、効率よく実行する仮想マシン。現状はPerl6の実行のみだが、開発元では別にPerlに限定しているわけではないようだ。
訳注2:
このインタビューが実際に行われたのは2001年4月ということで、上記の事件の直後であることから、ここで言及しているのだろう。
訳注3:
/.-Jの過去記事の中に登場した、RubyとPythonの比較についてのコメント内に幾つか有用なリンクが。
2) データ構造ライブラリ
by GrEp
――ボクはPythonはすぐにHackできちゃうので大好きなんですが、ただ一点気になるのは、適当なデータ構造のライブラリがない事です。そういうライブラリについてコメントや解説をお願いできませんか?
グイド:
Pythonの品質を高くしている一つの点として、巨大なデータ構造のライブラリを必要としないということがあるね。
例えて言うなら、1組が256個からなるスパナセットのような、各々のデータ型に応じて高度な最適化を施したライブラリを備える代わりに、Pythonにはほとんどどこでも効率的に使える僅かなスーパーツールがあるので、ツールの選択に悩む必要はないんだ。
もちろん、熟練したプロにとって、単方向リスト/双方向リスト/2分木などといったツールがないことはちょっと辛いかもしれない。でも、大抵の人々にとってはディクショナリとリストがあれば事足りるし、不慣れなプログラマにとっても、この二つのツールを選択するのを間違うことなんてまず有り得ない。
こんな風になっている理由は「単純さ」のためだけど、より豊富なデータ型を備えるように移行することを期待しているんだ。例として、「Set型」に対する提案(最初はモジュールの一つとして追加し、後に組込型にする)がある。
参考: PEP218 原文、PEP218のFe2+氏による邦訳版
3) [j | c]Python について
by seanw
――jPython(javaによる実装)と標準のcPython(オリジナルのC言語による実装)の関係の発展についてどう思いますか?
また、どちらの要素(言い換えれば、移植性 対 性能)が最近注目されている(MSの.NETのような)分散ソフトウェアに向けて優位性を持つという風に考えていますか?
グイド:
ちなみに、Jythonという新名称に変わった。http://www.jython.org/ を見てみれば分かるように、すでにPython2.1互換のリリースに向けて取り組んでいるよ。
私たちは、JPythonが最初CNRIのJim Huguninによって開発されていた頃からとても緊密に取り組んでいて、Jimと私はJavaでどうやって正しいセマンティクスを実装するかについてたくさんの議論を交わしたよ。Barry Warsawが引き継いでからもほとんど同じだね。
今ではヨーロッパのFinn BockとSamuele Pedroniがそれを引き継いだことで、ホワイトボードを前にして一緒に検討するという利便性は無くなってしまったけれど、彼らはPythonの開発者メーリングリストに参加しており、JythonとPythonの言語セマンティクスをできるだけ近いものにしようと共に取り組んでいるよ。
例えば、Scheme形式の継続(Stackless Pythonの開発者達によって熱心に提案されている)を言語に取り入れない理由は、それがJava仮想マシンでは実装できないからだ。Jythonの存在が私に、実装の詳細ではなく、より抽象的な言語の本質について考える事を思い出させてくれたという点で、非常に有用だと思っている。
ところで、個人的な考えとしては、CPythonの移植性はJythonより優れていると思う。実際、CPythonを各々のアーキテクチャでコンパイルする必要があるが、それでも、まともなJava仮想マシンがない環境よりCコンパイラのない環境の方が少ない。
JythonはすでにJavaプラットフォームを選択した(もしくは会社の方針やライバルの動向のために選択の余地がない)ほとんどの人に有用だ。そんな場合は、スクリプト用、及び拡張用言語としての選択になるね。
4) PythonにはCPANが必要では?
by po_boy
私がまだPerlで書いている理由の一つは、無数のモジュールを素早く簡単にCPANレポジトリとCPANモジュールを使って見つけ、インストールできるからです。もしPythonに同様の(Vaults of Parnassus のような、しかしもっと進化した)ものがあれば、私はきっとPerlを使うのをほぼ完全に止めるでしょう。
そのように感じたことはありますか？もしそうなら、なぜPythonでは同じもの、それかもっと進化したものを開発しないで来たのですか？その方面で私になにかお手伝いできることはありますか？
グイド:
ちょうどいい! catalog-sig での活動をチェックして頂きたい。参加すれば手伝ってもらえるよ。
今までカタログが整備されなかった理由の一つは、まずパッケージをインストールする良い手順を手に入れる必要があった、ということが挙げらる。distutilsが広く受け入れられている現在、このことは解決済みなので、カタログ活動には明るい未来像が見えている。
5) お気に入りのパイソンのスケッチ
by abischof
――この言語は例のコメディ集団にちなんで命名されたわけですが、モンティ・パイソンのスケッチ(※訳注4)ではどれがお気に入りなんですか? 個人的には、私は『羊のコンコルド』がお気に入りなんですけれど、それは別の機会にお話しするとして ;)
グイド:
実は、そういうのちょっとお腹いっぱいなのね。その件は過剰露出気味だと思うんだけど :-)
訳注4: スケッチ
モンティ・パイソンでの、(ショート)コントに対する呼称。
6) GPLとの不一致
by MAXOMENOS
――フリー・ソフトウェア財団では、Python 1.6b1以降で用いられるライセンスがGPLと互換性を持たないことに言及しています。特に、それについてこう言っています:
これは、フリー・ソフトウェア・ライセンスではあるが、GNU GPLとは矛盾する。第一の矛盾は、Pythonのライセンスが、アメリカのバージニア「州」の法律に準拠しているものであるが、GPLではそれを認めていないことである。
そこで、私の質問は2部構成で:
1. Pythonのライセンスが、バージニアの州法に準拠していると述べる、あなたの動機は何なんですか?
2. Pythonのライセンスが、将来的にまた、GPL互換になるということはありうるのでしょうか?
グイド:
2番目の質問から答えさせてくれ。私は、Python 2.1のGPL互換性に関して明言してくれるようFSFに頼んだ。で、彼らの弁護士からは、イエスともノーとも言わない冗長で重箱の隅をつつくような答えが返ってきたわけだ。これに関しては http://www.python.org/2.1/fsf.html で読むことができる。これには、かなり失望させられた。つまり、1.6.1のリリースをもって、大方私たちの手からは離れた、と思っていたわけだけれど、彼らは、交渉の各段階で、明らかに立場を変えるんだ。
個人的には、PythonがGPL互換になろうがもうどうでもいい――私はただ、FSFのために一肌脱いでやろうとしているわけだ。というのも、彼らは、Pythonを使うのが好きだから。面倒ごとをもたらしてくるのは彼らなのにも関わらず、なんで私がこれ以上やっかいを引き受けなきゃなんないのかって思う。
2問目については、きみたちのほとんどは、次の質問へと飛ばすべきだろうと思うね――ここの答えは、法的技術の話ばかりだし。去年なんて、弁護士と話し、耳を傾けることにいーーーーーーーーーっぱい時間を使ったんだ。:-(
どちらにせよ、だ。Python 1.6のライセンスを作成したのはCNRIで、2000年5月まで私はそこに勤めており、Pythonへ大いに取り組む事が出来たんだ(それ以前は、もちろんアムステルダムのCWIに勤めていた。そこでPythonの初期の取り組みができたことは感謝しないとね)。CNRIは、Pythonのバージョン1.3から1.6までの権利を持っている。だから、彼らには、ライセンスを選ぶあらゆる権利があるわけだ。
CNRIの弁護士は、そのライセンスには2つの目的を持つよう念頭において設計したのだ。(1) CNRIが最大限保護されるように。(2) オープン・ソースであること。(もし、(2)が、私のCNRI勤務に必須な条件でなければ、彼らは、Pythonなんて全然リリースしたくはなかっただろうね。:-) )
そのライセンスの特徴のほぼすべては、Pythonに失望したユーザーから起こされ得る訴訟に対して、CNRIを護るように機能するようになっている(そんなようなことがあったりするならばね。:-))。また、バージニア州の条項には、例外はない。CNRIの弁護士は、ライセンスの4項と5項(大文字になっているすべての免責条項)のみが、ある州においてどの法律や法廷が一般的放棄を支持するかを明らかにしていると訴訟の際に十分な保護機能となるのだ。いくつかの州には、一般的放棄を違法とする消費者保護法がある。だから、バージニアの条項がなければ、そういった州ではCNRIが訴えられかねないおそれがあるわけだ(自分自身は消費者として、消費者保護法にはおおむね好意がもてるけれど、フリーでダウンロードできるオープン・ソース・ソフトウェアにとってみては、一般的放棄なしでは、作者がリスクにさらされるとするCNRIに私は同意する。例えば、メリーランドが、オープン・ソース・ソフトウェアを特別に例外とするような法律を通過させようと考えているのは、うれしいと思う)。
Python 1.6.1は、2番目の「契約義務でのリリース」(1.6が1番目)で、1.6におけるGPL非互換性を1箇所だけ除いて全て解決すべく、CNRIのライセンスを変更することに特化したリリースだった。その非互換性とは何だったかとか、どうやって解決したのかとかは説明しないことにしておく。http://www.python.org/1.6.1/ の"accept license"のリンクを自分で見てくれればそれでいいと思う。該当する変更については、ライセンスの7節に全てあって、そこには、現在では、GPLに関係するある条件のもとでライセンスの他のある部分を利用不可にできるようにする、耐え難いような文面がいくつか含まれている。読んで泣いて頂戴。
FSFによれば、残る非互換性とは、ライセンスの"click-to-accept"機能だという。これは、CNRIを護るためのもう1つの機能だ。――弁護士たちは、このライセンスが、ユーザとCNRIの間で拘束力ある契約となるのに必要だと信じているわけだ。FSFはこれに必死で抵抗している。彼らの現在の立場は、こうだ。GPLでは、そんな(彼らの言葉で言う)「承諾の儀式」は要求しないのだから、どんなライセンスでもGPLと非互換となるのだ、と。それは、動かせないものに見合う不可抗力についての古い話に似ている。つまり、CNRIの弁護士は、今GPLを精読していて、CNRIのライセンスはGPLと完全互換だと主張している。というところで、どちらの弁護士を信じるかは、きみが選ぶことになるね。
いずれにせよ、私は、FSFに満足してもらうことを願って、2.1のライセンスから承諾の儀式はやめた。残念ながら、2.1のライセンスへのFSFの反応は、自分たちの立場をもういちど変えたというもので、現在は、ライセンスに別の変更をさせようとリクエストしている、というもののようだ。私は、とても、とても、うんざりしている……というわけで、次の質問へ移ろう!
訳注5: ライセンス
Pythonのライセンスはv2.0.1よりGPL互換となったため、この顛末は既に歴史的なものとなった。
7) 構造化のデザイン
by Xerithane
――まず最初に。私は、実際にはPythonで全くコードを書いていません。しかし、紹介記事や入門記事のほぼすべてを読んでいるので、文法と構造に関して把握できていると思います。
私は、Cでの開発をもう9年もやっており、他にも余るぐらいの言語を知っています。例えば、スクリプト系だと、シェルスクリプト、perl、PHPなどを含みます。
さて、それらすべては、if や for などの制御構造のグループ化にいわゆる「普通」の方式をとっています。
空白を基本とした文法規則を作るにあたって、何が理論的背景としてあったのでしょう?
そして、それがなぜ良いと思いましたか?
できれば「可読性」以外の答をお願いします。これまで、Pythonを知る人から得られた唯一の答がそれだったのです。
私の経験からは、中括弧({})を使うコードの方が空白を使うものより遥かに簡単に読めます。無意識に括弧を探してしまいますからね。コードの最初の一行が書かれてから20年を越えるような古いコードのメンテナンスを終えた今、Pythonのコードの寿命に興味があります。
それで第2の質問ですが、Pythonは20年をうまく生きのびるように思いますか?
そのように長く生きのびる理由は何だと思いますか?
グイド:
読みやすいという答えに何かご不満でも? 私は至極もっともな理由だと思うよ。
コードの読みやすさを気にしないだろうか? 正しくインデントされていないコードは嫌では? インデントを文法の一部にすることで、すべてのコードが適切にインデントされることを保証できる。
かっこを用いる場合だが、その置き方にいくつかの流儀がある。
つまり、開きかっこをifと同じ行におくか、それとも次の行にか? 次の行だとして、インデントするか、しないか? 閉じかっこも同様。
もしどれかの流儀に慣れると、他の流儀は読みにくくなり得る。
コードをざっと読む場合、多くの人はいずれにしろインデントを頼りにするので、
これはしばしば次のようなバグを見落とすことにつながる。
if (x 10)
x = 10;
y = 0;
まだ、腑におちない? ドナルド・クヌース氏は、1974年に「プログラム単位が十分小さい場合、インデントは最終的にはコードを構造化するための有効な手段になるだろう」と予測しているよ。
Pythonを試すほとんどの人は素早く習熟するし、最初は嫌っていたとしても最終的にはそのインデントの機能を好きになる。
これは、あなたにも起こり得ることだ!
だから、Pythonがあと20年もつことを心配などしていないね。
8) Pythonとその将来への*あなたの*考えは?
by Scarblac
――「ごちゃごちゃ難しいのより、白黒はっきりしてるのがいい」とか、「やり方はひとつだけあるのがいいね」とかいうみたいに、たくさんの「Pythonの黄金律」が(いや、それを何て呼ぶにしても)ありますね。私の知る限りでは、そういったものは、メーリングリストに投稿されたもので(よくジム・ピーターズが投稿してましたね)、後に規律となったものですね。Usenetでのアドボカシーにおける大いなる伝統では、そういったルールに歯向かうことを提案する人間は、批判されるわけです。でも、Pythonを見ていると、厳密なルールじゃなくて、よりいっぱいの実利主義というものを目にするのです。彼らが書き留めたそんな「黄金律」について、あなたは、どうお考えなんですか?
Pythonの将来についてはどう考えておいでですか? PEP(Python Enhancement Proposal)プロセスの登場から、新たな機能のアイディアがたくさん進められていますし、良い言語へと急速に変化することには多くの人が居心地悪く思ってもいます。(でも、Python 2.1は、すばらしいですよ! やったね!) いつか、Pythonが完成を迎える日が来ると願ってたり考えてたりするんですか? そうでないとしたら、果てしなく機能を加え続けていくという代替案になるのですか? "Python 3000"は、取り組むに理想的なPythonの類のひとつのアイディアだったんだと思いますが、私の理解では今ではPythonはもっとゆっくりと進化していくんだろうと思います。
グイド:
ジム・ピーターズ の 「Zen of Python」(※訳注6) のことを言っているね。
そういったルールが、Python Humorのページに投稿されたのは偶然なんかじゃないんだ。
それらのルールは、機能すると便利だ。でも、力の入ったアプリケーションには警鐘を鳴らすものもいくつかある(例えば、「とかく実用性を求めてくと、ちょっとはずれちゃうこともあるけどね」や「やらないよりは今やるべき」)。
Tシャツに、「やり方はひとつだけあるのがいいね」なんてプリントしつつも、ラリー・ウォールの言うTMTOWTDIをからかってたりしていたりする。Pythonの禅のルールは、実際にはこう読める。「間違えようのないやり方がひとつだけあるのがいいね。」 これには、いくつかニュアンスがあるわけだ。
Pythonは、進化を遂げるのに非常によく備えられた形で出発した。つまり、言語自体を改変することなく(C拡張モジュールとPythonモジュールの)2つのレベルで拡張可能だったのだ。私たちは、よりよく進化させるために新しい機能をときどき付け加える。例えば、パッケージの名前空間によって、そのライブラリでもっともっと大量のモジュールを持てるようにするとか、distutilによって、サード・パーティのパッケージを追加することがより簡単になる、といった。
Pythonの変化の速度についてコミュニティからの苦情を聞いている。それで、私は、言語をあまり急速に変えすぎないように気を遣っていくつもりだ。次のまとまった変更では、おそらく、複雑さを*減殺*することが狙いとなるだろう。例えば、(32/64ビットの整数と多倍長整数の区別を取り払うような)Pythonの数値システムの簡素化をもくろんでいるPEPがあるし、――言語の意味論のもうひとつの簡素化として――タイプとクラスの区別をなくそうと真剣に考えはじめたところだ。
訳注6: Zen of Python邦訳版
9) 最狂のPython利用法
by Salamander
――いままでに見つけたPythonの使い方で、一番驚いたやつってどんなのですか?
つまり、「そんなことするなんて信じられない!」っていうリアクションをしちゃった最強のやつは?
グイド:
いくつか、変わってると思うやつは見つけた。
私が偶然出会った、一番邪悪なコードは、ラムダ演算子によるマンデルブロ集合(※訳注6)で、これについては http://www.python.org/doc/FAQ.html#4.15 を見てくれ。
Digital Creations(※訳注7)が、ハイ・パフォーマンスの、完全にトランザクションに対応した複製オブジェクト・データベースをPythonで書いている。これは間違いなく、私がPythonを作り始めたときに良かれと思ったあり方を超越したものだ。
LANLとかLLNLみたいな国立物理研究所では、数百のプロセッサを持った並列スーパーコンピュータ用のPythonを持っているひともいる。これは、かなり見事だね。
でも、私の*大好きな*Python利用法は、騒ぎ立てずに、言語教育でプログラミングの原理を教えること。それを考えてくれ――次の世代の話だね。
訳注7 : Digital Creations
Zope
の開発元の旧名称。
訳注8 : ラムダ演算子によるマンデルブロ集合
Ulf
Bartelt氏作。FAQは現在、項目がかなり増え、対応する番号が変わっているため、
上記のURLからはコードを参照できない。
参考: ラムダ演算子に
よるマンデルブロ集合(新URL)。
--Guido van Rossum (ホームページ: www.python.org/~guido)
# 編集者様へ
何度かプレビューを試しましたが＜PRE＞ 〜 ＜/PRE＞タグが効かないようです。
問7にグイド氏の回答の中にコードの例があり、PREタグで囲ったのですが、うまく表示されません。
本家の記事では その部分はPREで囲ってありちゃんと表示されています。
http://slash-interview.osdn.jp/cgi-bin/wiki.cgi?GuidoVanRossum
からHTMLのソースにアクセスできますので、
問7のコードの部分は、こちらからPREタグを含んだ形でソースをコピー&ペーストしていただけますでしょうか。
よろしくお願い致します。