3ケ月前(2008年12月3日)、Python 3.0 (別名、Python 3000)が正式にリリースされた(リンク)。言語作成者であるGuido van Rossum氏がこの新たな革命的なPythonバージョンを思い描いてから、ほぼ9年が経った。Python 3.0はその言語の以前のバージョンとの下位互換性を絶っている。
2007年のブログ記事で、Guido氏はPython 3.0を着想した経緯(リンク)について書いた。
長期間にわたり、後方互換性を経つことなしに、修正不可能な遺憾や不具合のリスト以外はありませんでした。Python 3000を前進する最高の言語にすることに賛成して、後方互換性を絶つために、Python 3000を最初のPythonリリースとする考えです。
インタビューで、Guido氏はその後の経過(リンク)について以下のように述べた。
実際に作業を開始したのは、つまり実際にそれを設計して、すべてに同意することですが、約3年前のことです。ちょうどここGoogleでPythonに関わる時間が増えた頃です。長い間、そのプロジェクトの推進に携わり、多くの人びとを興奮の渦に巻き込みました。PyCon、Euro Python、その他のカンファレンスで例年の講演をしました。ここ1年、デベロッパコミュニティが最終的な詰めをして、リリースに向けた準備をしている間、わたしはずっととは言わないまでも、大部分をくつろいでその様子を傍観していました。
Python 3.0がPython 2.xとの後方互換性を絶ってから、そのリリースはPythonバージョン2.6のリリースに合わせられた。新機能の多くを便利に、安全に試す方法を提供 する。Pythonの以前のバージョンで実施されたように、2.6バージョンはそれ以前のバージョンと完全に互換性があるが、Python 3.0の多くの新機能(リンク)を搭載している(その中には、巧妙な「from future import」文を使用することで、利用可能になるものがある)。
Python 3.0の新機能
Guido氏は、Python 3.0での目立った機能は「非常に優れたUnicodeサポートおよび不正に書き換えられたデータベースのクリーンアップ」だと述べた。また、いかにも完 全なunicodeサポート(リンク)は、変更された主なアスペクトの1つである。Guido氏は以下のように書いた(リンク)。
すべてのテキストはUnicodeです。しかしながらエンコードされたUnicodeは、バイナリデータとして表されます。概念上のこの変更の結果とし て、Unicodeを使用するすべてのコード、エンコーディングまたはバイナリデータは、大概変更する必要があります。2.xの分野において、エンコード および非エンコードテキストが混合しているのをどうにかしなければならない、多数のバグがありました。そうであるように、変更は良い方向へ 向かうものです。
Python 2.xはUnicodeをサポートしたが、(古い)strタイプと(新しい)unicodeタイプがあった。Python 3.0では、すべての文字列はユニコードであり(strはユニコード文字列)、バイトシーケンスを保持するバイトと呼ばれる、新タイプがある。
Python 3.0のその他の変更は、以下のとおりである。
- Printは関数 - print文はprint()関数(リンク)に取って代わり、キーワード引数が、古いprint文のほとんどの特殊な構文を差し替える(from future import print_functionを使用することでPython 2.6のこの機能を試すことができる)。これについて詳しくは、PEP 3105 -- Make print a function(リンク)を参照のこと。
- リストではなくビューおよびイテレーター - 既知のAPIによっては、もはやリストを返さないものもある。ディクショナリのdict.iterkeys()、dict.itervalues()およ びdict.iteritems()メソッドは、削除された。その代わり、.keys()、.values()および.items()を使用することがで きる。それらはキーや値のコピーであるリストの代わりに軽量の、セットのようなコンテナオブジェクトを返すように改訂されている。ここでのメリットは、 キーやアイテムでコピーすることなく、一定の操作を実行する機能である。
- 整数 - つねに浮動小数を返すことで、除算演算子(「/」)の曖昧さをなくす。以前のバージョンでは、引数がintsまたはlongsの場合、除算の数学の結果の floorを返し、引数がfloatsまたはcomplexの場合、妥当な近似値を返した。この機能は、from future import除算を使用することでバージョン2.6で使用できる。これについて詳しくは、PEP 238 -- Changing the Division Operator(リンク)を参照のこと。
- さまざまな構文の変更(リンク)
バージョン3.0への遷移をできるだけ簡単にすることに関して、さまざまな考えが考案された。バージョン2.6へ多数の機能をバックポートすることに加え て、新たなコマンドラインスイッチがあり、Python 3.0で削除される予定の機能に関して警告を発する。このスイッチでコードを実行することができ、3.0にコードを移植するためにどれだけの作業が必要に なるかを確認することができる。さらに、Pythonプログラムである「2to3」(リンク)と呼ばれる新たなコードが、Python 2.xソースコードを読み出し、一連のフィクサーを適用して、有効なPython 3.xコードに変換する。またGuido氏は、以下のように付け足した(リンク)。
実際、コードを修正するのではなく、変更する統合された違いをプリントするように要求することができるモードを備えた、2、3のツールがあります。そうし たければ、ファイルごとの割合でそれを見直し、決定します。「素晴らしい。良く動作している」。または、注意深く見直すと、ツールが不適切な動作をしてい る場合があることに気が付くかもしれません。それから、そのパッチファイルを取り出して、適用されるべきパッチを手動でやり直します。そのように、ツール が大量の作業を手伝ってくれます。それは3.0へPython 2.6で起こっていることの先例を作りました。
誰かがPython 2.6または3.0を開発すべきか?Guido氏は、以下のように考えている(リンク)。
3.0か2.6のどちらを使うか、決めるのは個人の選択です。この時点で保守的なスタンスをとって、後に取り残されるようなリスクは負いたくありません。 2.6は、Python 3.0と同様に、同じ中心的なPythonデベロッパによって、十分にサポートされる予定です。同時に、われわれは3.0の重要性や品質にあまり重きを置 いていないわけではありません。ですから、パッケージの依存関係や未だに3.0に移植されていないサードパーティーソフトウェア、または他の人が他のバー ジョンを使用しているような環境で作業している場合などの外部的な要求によって、阻害されません。
PythonoおよびPythonコミュニティのもっとも良く知られた側面の1つは、後方互換性を十分に考慮した、バージョンからバージョンへの保守的な 前進である。Pythonコミュニティは、他のコミュニティが夢にしか見れないことを可能にすることができるということを示した。それは、後方互換性を犠 牲にしてより良いバージョンを生み出すことである。Javaコミュニティは何年もこの考えをあたためていたが、バージョン1.2(またの名を、Java 2)以来、既存のコードを破壊することを恐れて「悪人」は触れられなかった。