2007年の8月に、オブジェクト指向スクリプト言語Pythonの次期バージョンである「Python 3.0」のα1がリリースされました。12月には引き続いてα2がリリースされています。Python 3.0は、2008年8月に予定されている正式版リリースに向け、順調に開発が進んでいます。
この特集では、「Python 3000」という愛称で呼ばれるPythonのバージョン3.0について、現時点でわかっていることをお伝えします。機能追加や仕様変更の詳細についてだけでなく、実働するコードや2.xからの移行方法についても、必要に応じて掲載していく予定です。
実際にPython 3.0の話に移る前に、ちょっとだけ時間を過去に戻してみましょう。
Python 3000にまつわる昔話
「Python 3000」という言葉が初めて世の中で使われたのは、私が知る限り今から8年前のことです。著名なPythonハッカーであるJim Fulton（現Zope corp. CTO）が投稿した、Pythonの名前空間に関する質問にメールに答える形で、Guidoが「Python 3000」という名前について言及しています。
当時、Pythonの最新バージョンは1.5.2で、次期バージョンの1.6を開発している最中でした。「時期が不確定な未来」という意味を込めて、当時の次期バージョンであったPython 2をそう呼んだのでしょう。2000年といえば新しい千年期の始まりの年です。「次期バージョンが出るまではもう1000年かかる」という、シニカルなジョークだったのかも知れません。
ところで、Python 2.0は同年リリースされたPython 1.6と同じ年、2000年の末にリリースされました。2.0は、1.6の機能をほぼそのまま継承する形でリリースされています。
同時期、Pythonの開発はGuidoを筆頭とする専門の開発チームに移り、リリース元も変わっています。2000年という年は、Pythonがプログラミング言語として独り立ちを果たした時期だったのです。このナンバリングには政治的、マーケティングな意味があったように推測しています。そういう意味では、Python 2.0は2000年当時Giodoが思い描いていた「Python 3000」にはほど遠い存在だったはずです。
Zen of Python
2001年、スラッシュドットのインタビュー（邦訳）にて、Guidoは再びPython 3000について言及しています。質問に答える中で、Pythonの精神に触れた「Zen(禅) of Python（邦訳）」の一節を引用しています。
「誰にとっても明確な手法が、一つだけあることが好ましい（There should be one-- and preferably only one -- obvious way to do it.）」
「言語仕様の一貫性」について言及したこの文章は、Pythonの言語としての哲学をよりよく表した一文として、たびたび引用されています。Pythonの現在の仕様だけでなく、Pythonが目指すべき姿をよく体現した言葉だと言えます。
Pythonの将来像について答える前に、インタビューの原文では、以下のような含蓄のある言葉を挟んでいます。
「良いソフトウェアは生まれた時から進化する能力を備えている。そして、複雑さをコントロールしながら進化していくものだ（Good software has the ability to evolve built in from the start, and evolves in a way that keeps the complexity manageable.）」
続いて、Pythonの目指す次のステップについて「（言語としての）複雑さを減らすことが目的」と語っています。Guidoは当時から、Pythonを言語としてより長く発展させるために、シンプルさや一貫性を保つことが必須条件だと考えていたわけです。
後方互換性を崩す仕様変更
2001年のインタビューで直後にGuidoが触れている通り、Pythonには複雑さを助長し一貫性を崩す仕様が存在しています。そのような仕様のいくつかは、Pythonが設計された初期段階の間違いから来ていると、Guido自身が認めています。2002年のOSCONでは、「Python Regrets（Pythonへの後悔：プレゼン資料）」と題した講演を行っています。この講演の中で、Guidoは言語の設計者自らPythonの設計上の間違いを示すという形で、Pythonの本来あるべき姿を逆説的に示して見せています。
Pythonの「複雑さを減らす」変更のうちいくつかは、Python 2世代に行われました。2.2で導入された「新スタイルクラス」はその代表例と言っていいかもしれません。ただし、そのような変更にも「後方互換性を守る」という足かせがありました。
Pythonはいまだに2種類の整数型を持っています。辞書型のキーを検査するには「has_key()」メソッドを使う方法と演算子「in」を使う方法の2種類が存在するのです。生成するリストの大きさによって使い分ける必要がある組み込み関数ragne()とxrange()、BaseHTTPServerやHTMLParserのように、PEP 8（邦訳）の推奨する命名規則に従わないモジュール。さまざまな意味合いで一貫性を崩す仕様のほとんどは、後方互換性を残すために変更できず、残されたままでいます。
PEP 3000
これまでPythonは、過去のソフトウェア資産を最大限に活用できるよう、できる限り後方互換性を残す形でバージョンアップを続けてきました。しかし、Pythonに残された非Pythonicな仕様を完全に取り除くには、後方互換性を崩す仕様変更が必要であることは誰の目にも明白でした。
2004年の10月には、Python 3000の名前がPEP（新規追加当時のPEP）に登場します。PEP 3000では、後方互換性を崩す変更を含むバージョンとして、Python 3000とPythonのバージョン3.0を公式に紐づける形で言及しています。
ただし、この時点ではPython 3.0には「空想上の（hypothetical）」という前置きがありました。Guido自身、2005年のPyConで、当時勤めていた会社が「Python 3000を作るための時間をくれない」と愚痴をこぼしていたので、開発リソースは十分ではなかったのでしょう。それからの数年は、Python 3.0を現実のものとするための議論や思考実験に費やされていました。
開発開始、そしてαリリース
Python 3000の開発が本格的に始まったのは2006年のことです。2005年の末にGuidoがGoogleに転職を果たし、Pythonのために割ける時間が大幅に増えたことが、Python 3000の開発を進めるために大きな要因になっていたように思われます。
2006年3月には、Python 3000開発用のメーリングリストが立ち上がっています。前後して、2006年4月にはPEP 3000がGuido自身によって書き換えられています。新しいPEP 3000には「空想上の」という言葉はもうありません。また、Python 3.xと平行してPython 2.xの開発が続けられることなど、リリースの戦略などについても触れています。
2006年の8月には、CNRI時代からの朋友で、Guidoに先んじてGoogleに転職していたJeremy Hyltonにスプリント(短期開発イベント)を先導するよう呼びかけます。この頃から、Python 3000の開発はより活発になっていったようです。
Python 3000の開発が本格化した後約1年で、αバージョンのリリースに至っています。開発は、Python 2.xをベースに進められいます。ゼロから新しいコードを書くのではなく、既存のコードベースを最大限に活用しています。実現可能と思われるスケジュールを確実にヒットする、という現実路線が採られているのです。
Python 3000がαリリースに至るまでを振り返ってみてよくわかるのは、Guidoの目指すところが常に一貫しているということです。しかし、Pythonをより一貫性のあるシンプルなプログラミング言語に脱皮させるためには、いろいろな必要条件を満たす必要があったことも事実でした。Pythonが世の中に広く受け入れられてGoogleのようなスポンサーに恵まれ、十分な開発リソースを手に入れる必要がありました。
利用者を含めたコミュニティの側にも、新しい変化を受け入れる準備が必要なはずです。Python 3000には、ユーザの「民族大移動」を促すさまざまな仕掛けが備わっています。Python 3.0の正式版に先立ってリリースされる予定のPython 2.6では、3.0非互換のコードに対して警告を与えるオプションや、コードコンバータなどが同梱される予定です。
また、3.x系の開発と共に、少なくとも数年は2.xの開発が続くことが予告されています。Guido自身、「Python 3が広まるのは3.1か、もしかしたら3.2の頃だろう」と言っています。ユーザの移行に関しても、明確なビジョンが示されています。
今年の後半には、ほぼ10年越しで計画されてきたPython 3000の正式版がリリースが予告されています。2008年は、これまでのPythonの歴史の中で、最も大きなマイルストーンとなる年なのです。
次回は、数値型や文字列型といった「組み込み型」を中心に、Python 3000での変更点を見て行きたいと思います。
