What's New In Python 3.0
************************

著者:
   Guido van Rossum

This article explains the new features in Python 3.0, compared to 2.6.
Python 3.0, also known as "Python 3000" or "Py3K", is the first ever
*intentionally backwards incompatible* Python release. Python 3.0 was
released on December 3, 2008. There are more changes than in a typical
release, and more that are important for all Python users.
Nevertheless, after digesting the changes, you'll find that Python
really hasn't changed all that much -- by and large, we're mostly
fixing well-known annoyances and warts, and removing a lot of old
cruft.

この記事は全ての新機能を完璧な仕様を示そうとはしませんが、便利な概要に
ついては説明しようとしています。 全詳細については Python 3.0 のドキュ
メントや、本編で引かれている多くの PEP を参照してください。 特定の機能
の実装や設計原理について完全に理解したいなら、通常のドキュメントよりも
詳しいことが書いてある PEP を見るとよいでしょう。 しかし、一旦機能が完
全に実装されると、普通 PEP は最新の状態に保たれないことに注意してくだ
さい。

この文書で全項目に触れるべきなのですが、時間の制約のためそうではありま
せん。 いつもの新リリースのように、 ソース配布の *Misc/NEWS* には些細
な変更についても詳細な情報があります。


よくある悩みの種
================

このセクションは Python 2.5 に慣れていたら躓いてしまいそうな少数の変更
の一覧です。


print関数
---------

"print" 文は "print()" 関数に置き換えられ、古い "print" 文の特殊な文法
の殆どがキーワード引数で置き換えられています (**PEP 3105**)。 例:

   Old: print "The answer is", 2*2
   New: print("The answer is", 2*2)

   Old: print x,           # Trailing comma suppresses newline
   New: print(x, end=" ")  # Appends a space instead of a newline

   Old: print              # Prints a newline
   New: print()            # You must call the function!

   Old: print >>sys.stderr, "fatal error"
   New: print("fatal error", file=sys.stderr)

   Old: print (x, y)       # prints repr((x, y))
   New: print((x, y))      # Not the same as print(x, y)!

項目間の区切りをカスタマイズすることもできます。例:

   print("There are <", 2**32, "> possibilities!", sep="")

これは以下を出力します :

   There are <4294967296> possibilities!

注釈:

* "print()" 関数は、古い "print" 文の "ソフトスペース" 機能をサポート
  しません。例えば Python 2.x では、 "print "A\n", "B"" は ""A\nB\n""
  を出力していましたが、 Python 3.0 では、 "print("A\n", "B")" は
  ""A\n B\n"" を出力します。

* 最初は、対話モードで古い "print x" を何回もタイプしてしまうでしょう
  。代わりに "print(x)" とタイプするよう再教育してください。

* "2to3" ソース変換ツールを使うと、すべての "print" 文が "print()" 関
  数呼び出しに自動的に置換されるので、大きなプロジェクトでもさほど問題
  にならないでしょう。


リストからビューおよびイテレータへ
----------------------------------

いくつかの良く使われている API はもはやリストを返しません:

* "dict" の "dict.keys()", "dict.items()" そして "dict.values()" メソ
  ッドはリストの代わりに "views" を返します。 例えば: "k = d.keys();
  k.sort()" は上手く動きません。 代わりに "k = sorted(d)" を使ってくだ
  さい (これは Python 2.5 でも動作し、効率的です)。

* "dict.iterkeys()"、 "dict.iteritems()"、 "dict.itervalues()" メソッ
  ドはもうサポートされません。

* "map()" と "filter()" はイテレータを返します。もしも本物のリストが必
  要で、全ての入力シーケンスが同じ長さの場合であれば、簡単に直すなら
  "map()" を "list()" で包みます。例えば "list(map(...))" という具合。
  ですがより良いのは、大抵はリスト内包を使うことです (特に元々のコード
  が "lambda" を使っている場合)。あるいはコードを、リストを全く必要と
  しないように書き換えましょう。とりわけトリッキーなのは、関数に副作用
  を起こさせるために呼び出される "map()" です; この場合確実な変換は普
  通に "for" ループを使うことです (そもそもリストを作ること自体が無駄
  遣いでしょう)。

  入力シーケンスの長さが同じとは限らないならば、 "map()" は最も短いシ
  ーケンスが消費されつくすと処理をやめます。Python 2.x での "map()" 用
  法と全く互換にするにはシーケンスを "itertools.zip_longest()" で包ん
  でください。例えば "map(func, *sequences)" を "list(map(func,
  itertools.zip_longest(*sequences)))" とします。

* "range()" は "xrange()" のように振る舞います。ただし、任意のサイズの
  値で動作します。 "xrange()" は削除されました。

* "zip()" はイテレータを返します。


順序比較
--------

Python 3.0 で順序比較のルールが簡単になりました。

* 順序比較演算子 ("<", "<=", ">=", ">")  は、そのオペランドが自然な順
  序づけを持たない場合 TypeError 例外を送出します。  "1 < ''", "0 >
  None" または "len <= len" のような式は無効になり、 "None < None" は
  "False" を返す代わりに "TypeError" を送出します。その結果、 不均一な
  リスト（訳注：比較不能な型からなる要素が混在するリスト）のソートは意
  味がなくなりました。 -- 全ての要素は互いに比較できなければなりません
  。これは "==" と "!=" 演算子には適用されないことに注意してください:
  別々の比較不可能な型のオブジェクトを比較すると常に、互いに等しくない
  と評価されます。

* "builtin.sorted()" と "list.sort()" メソッドは比較関数を与える *cmp*
  引数を受け取らなくなりました。 かわりに *key* 引数を使用してください
  。 *key* と *reverse* 引数は "キーワード専用" となったことに注意して
  ください。

* "cmp()" 関数は廃止され、 "__cmp__()" 特殊関数はもはやサポートされま
  せん。ソートには "__lt__()" を使用し、 "__hash__()" には "__eq__()"
  を 、必要に応じて他の高級比較 (rich comparison) を使用してください。
  (もし "cmp()" の機能が必要なら、 式 "(a > b) - (a < b)" を "cmp(a,
  b)" の代わに使用できるはずです)


整数
----

* **PEP 237**: 基本的には、 "long" は "int" に改名されました。これは、
  整数型の唯一の組み込み型になり、 "int" と名付けられていますが、古い
  "long" 型とほぼ同じように振る舞います。

* **PEP 238**: An expression like "1/2" returns a float.  Use "1//2"
  to get the truncating behavior.  (The latter syntax has existed for
  years, at least since Python 2.2.)

* 整数の上限がなくなったため、"sys.maxint" 定数は削除されました。しか
  しながら、通常のリストや文字列の添え字よりも大きい整数として
  "sys.maxsize" を使うことができます。 "sys.maxsize" は実装の "自然な"
  整数の大きさに一致し、同じプラットフォームでは (同じビルドオプション
  なら) 過去のリリースの "sys.maxint" と普通は同じです。

* long 整数の "repr()" はもはや末尾に "L" を持ちません。そのため、無条
  件に "L" を取り除くコードは代わりに最後の数字を取り除いてしまうでし
  ょう。 (代わりに "str()" を使用してください。)

* 8進数リテラルが "0720" の形でなくなりました。代わりに "0o720" を使っ
  てください。


Unicode 対 8 ビット、ではなく、テキスト対データに
-------------------------------------------------

バイナリと Unicode について知っていると思っている全てが変わりました。

* Python 3.0 でのコンセプトは、Unicode 文字列と 8 ビット文字列、という
  対比ではなくて、 *テキスト* と (バイナリ) *データ* の違いと考える、
  というものです。全てのテキストは Unicode です; 一方で *エンコードさ
  れた* Unicode はバイナリデータとして表現されます。テキストを保持する
  のに使われる型は "str" で、データには "bytes" を使います。2.x での状
  況との最大の違いは、Python 3.0 でテキストとデータを混ぜようとすれば
  "TypeError" となることです。Python 2.x では Unicode と 8 ビット文字
  列を混ぜたとすれば、8 ビット文字列がたまたま 7 ビット (ASCII) バイト
  だけから出来ていれば動くし非 ASCII バイトがあれば
  "UnicodeDecodeError" となっていたでしょう。この、データ値に依存した
  振る舞いが、何年にも渡って夥しい数の悲劇を生み出していました。

* この変更からの帰結として、Unicode、エンコーディング、あるいはバイナ
  リデータを使うほとんど全てのコードは、原則として修正する必要があると
  思います。この変更は進歩のための破壊です。というのも 2.x 世界には、
  エンコードされたテキストとそうでないものをごっちゃにしている膨大な数
  のバグがあるはずだからです。Python 2.x のうちから準備しておくには、
  まずは全てのエンコードしていないテキストに "unicode" を使い、 "str"
  はバイナリとエンコードされたデータだけに対して使うことから始めてくだ
  さい。そうしておけば "2to3" ツールがあなたのためにほとんどの仕事をし
  てくれるでしょう。

* Unicode テキストのリテラルに "u"..."" を使うことはもはやできません。
  しかし、バイナリーデータのリテラルには "b"..."" を使わなければなりま
  せん。(---訳注: この "u"..."" は Python 3.3 で再び使えるようになりま
  した。 ---)

* "str" 型と "bytes" 型を混ぜて使うことは出来ませんから、それらはいつ
  でも明示的に変換しなければいけません。 "str" から "bytes" にするには
  "str.encode()" を使ってください。そして "bytes" から "str" にするに
  は "bytes.decode()" を使います。それぞれ "bytes(s, encoding=...)" 、
  "str(b, encoding=...)" を使うことも出来ます。

* "str" がそうであるように、 "bytes" は *immutable* です。これとは独立
  させて *mutable* 型として、バッファ化されたバイナリデータを保持する
  ための "bytearray" が用意してあります。 "bytes" を受け付ける API の
  ほぼ全てが "bytearray" も許容します。その mutable API は
  "collections.MutableSequence" に基づいています。

* raw 文字列リテラル内にある全てのバックスラッシュが「字句通り」に解釈
  されます。つまり "'\U'" も "'\u'" も、 raw 文字列内にあっては何ら特
  別に扱われないということです。例えば "r'\u20ac'" は Python 3.0 では
  6 文字の文字列です。Python 2.x では "ur'\u20ac'" が単一の「ユーロ」
  文字であったのにです。(無論この変更は raw 文字列リテラルについてだけ
  のもので、ユーロ文字は Python 3.0 で "'\u20ac'" です。)

* 組み込みであった "basestring" 抽象型なんてものは削除されたのです。
  "str" をお使いなさい。 "str" と "bytes" は基底クラスを共有するのを正
  当化するのに足るほどには、機能的に共通していないのです。 "2to3" ツー
  ル (後述) は "basestring" を片っ端から "str" に置き換えてくれます。

* テキストファイルとして開かれたファイル (これは従来どおり "open()" で
  のデフォルトのモード) は、 (メモリ内の) 文字列と (ディスクでの) バイ
  ト列との写像をするのに、常にエンコーディングを使います。バイナリファ
  イル (モードに "b" を付けて開いたもの) はメモリ内では常にバイト列を
  使います。このことで、もしもファイルが誤ったモードやエンコーディング
  で開かれようとすると、I/O はきっと口やかましく失敗します。こっそり正
  しくないデータを生み出すのではなく。それに加えて、ファイルを開く際に
  は Unix ユーザでさえもこれからは、 (テキストかバイナリかの) 正しいモ
  ードを選択する必要があるということです。プラットフォームにはそれ特有
  のデフォルトエンコーディングがあります。Unix 的プラットフォームでは
  これは環境変数 "LANG" にセットされているかもしれません (あるいは時々
  ほかのプラットフォーム特有の、ロケールに関係した環境変数にもセットさ
  れています)。全てとは言いませんが多くの場合は、システムのデフォルト
  は UTF-8 です; ですが決してこのデフォルトを当てにすべきではありませ
  ん。純粋な ASCII テキスト以上のものを読み書きするどんなアプリケーシ
  ョンも、きっとエンコーディングをオーバライド出来る手段を持つべきです
  。 "codecs" 内にあるエンコーディングを熟知したストリームを使うことは
  、今ではもう必要なくなりました。

* "sys.stdin", "sys.stdout", "sys.stderr" の初期値はいまでは Unicode
  のみのテキストファイルです (つまりそれらは "io.TextIOBase" のインス
  タンスです)。バイト列データをそれらのストリームで読み書きするには、
  "io.TextIOBase.buffer" 属性を使う必要があります。

* ファイル名は、API へは (Unicode) 文字列を渡し、 (Unicode) 文字列が返
  ります。これにはプラットフォーム特有の問題があるかもしれません。とい
  うのも、いくつかのプラットフォームではファイル名は任意のバイト文字列
  だからです。(他方では、Windows ではファイル名はネイティブに Unicode
  で格納されています。) 次善策として、ほとんどの API (たとえば
  "open()" と "os" モジュール内の多くの関数) はファイル名として、文字
  列だけでなく "bytes" を受け付け、そして少しの API は "bytes" を返す
  かどうかを要求出来る手段を持っています。それゆえに "os.listdir()" は
  引数が "bytes" インスタンスであれば "bytes" のリストで返し、
  "os.getcwdb()" はカレントディレクトリを "bytes" で返します。
  "os.listdir()" が文字列のリストで返す際、適切にデコード出来ないファ
  イル名は "UnicodeError" とはせずに無視されることにご注意ください。

* "os.environ" や "sys.argv" のようないくつかのシステム API にも問題が
  ありえます。システムにより利用可能とされるべきバイト列がデフォルトエ
  ンコーディングで解釈不能な場合です。環境変数 "LANG" をセットしてプロ
  グラムを再実行することが、おそらく最善のアプローチです。

* **PEP 3138**: 文字列への "repr()" はもう非 ASCII 文字をエスケープし
  ません。ただし、制御文字、Unicode 標準で印字不可状態のコードポイント
  は今でもエスケープされます。

* **PEP 3120**: ソースのエンコードのデフォルトが UTF-8 になりました。

* **PEP 3131**: 非 ASCII 文字を識別子として使用することが出来るように
  なりました。 (そうはいっても標準ライブラリは、コメント内での貢献者の
  名前以外では ASCII だけのままです。)

* "StringIO" および "cStringIO" モジュールは廃止されました。その代わり
  "io" モジュールをインポートして、テキストやデータには "io.StringIO"
  や "io.BytesIO" を使用してください。

* Unicode HOWTO を参照してください。Python 3.0 向けに更新されました。


構文の変更の概要
================

このセクションは Python 3.0 における全ての *構文の* 変更についての簡単
な概要です。


新たな構文
----------

* **PEP 3107**: 関数引数と戻り値のアノテーション。これは関数のパラメー
  タと戻り値へのアノテーションを付ける標準的な手段を提供します (訳注:
  annotation を強いて訳せば「注釈」)。そのようなアノテーションには、実
  行時に "__annotations__" 属性を調べること以外には何の意味付けもされ
  ていません。メタクラスやデコレータ、フレームワークを通じた実験を促進
  することが意図されています。

* **PEP 3102**: キーワード専用引数。 パラメータリスト中で "*args" のあ
  とに現れる名前付きパラメータは、呼び出す際には *必ず* キーワード引数
  の構文を使う必要があります (---訳注: "def fun(*a, kw):" という定義で
  "fun(1, 2, 3)" は NG で "fun(1, 2, kw=3)" としなければならない。ここ
  までは 2.x と同じ ---)。 この PEP により、可変引数リストを受け取らず
  にキーワード専用引数だけを許したい場合にそれを主張するために剥き出し
  の "*" をパラメータリスト内に書けるようになりました (---訳注: "def
  fun(*, kw):" と定義出来る。この定義では "fun(kw=1)" としてしか呼び出
  せない。 "fun(1)" はダメ。---)。

* クラス定義内で、基底クラスのリストのあとでキーワード引数が許されるよ
  うになりました。これは metaclass を指定するための新しい規約 (次セク
  ション参照) に使われるものですが、 metaclass サポートだけのためだけ
  でなく他の目的に使うことも出来ます。

* **PEP 3104**: "nonlocal" statement.  Using "nonlocal x" you can now
  assign directly to a variable in an outer (but non-global) scope.
  "nonlocal" is a new reserved word.

* **PEP 3132**: 拡張されたイテレータのアンパック。 "a, b, *rest =
  some_sequence" のようなことを書けるようになりました。 "*rest, a =
  stuff" も出来ます。 "rest" オブジェクトは常に (空かもしれなくても)
  リストです; 右辺には任意のイテラブルを置けます。例えば:

     (a, *rest, b) = range(5)

  これは *a* に "0" を、 *b* に "4" を、そして *rest* に "[1, 2, 3]"
  をセットします。

* 辞書内包表記: "{k: v for k, v in stuff}" は "dict(stuff)" と同じ意味
  ですが、より柔軟です。 (これは **PEP 274** で支持されています。)

* セットリテラル、例えば "{1, 2}"。"{}" は空の辞書であることに注意して
  ください。空のセットには "set()" を使用してください。セットの内包表
  記もサポートされました。例えば "{x for x in stuff}" は "set(stuff)"
  と同じ意味ですが、より柔軟です。

* 新たな8進数リテラル、e.g. "0o720" (2.6 で既にありました)。古い8進数
  リテラル ("0720") は廃止されました。

* 新たなバイナリリテラル、e.g. "0b1010" (2.6 で既にありました) と、関
  連する新しい組み込み関数 "bin()" が導入されました。

* "b" または "B" で始まるバイトリテラルと、関連する新しい組み込み関数
  "bytes()" が導入されました。


変更された構文
--------------

* **PEP 3109** と **PEP 3134**: 新たな "raise" 文のシンタックス:
  "raise [*expr* [from *expr*]]"。以下を参照してください。

* "as" and "with" are now reserved words.  (Since 2.6, actually.)

* "True"、"False"、および "None" が予約語になりました。(2.6 では既に
  "None" が部分的に制限されていました)

* Change from "except" *exc*, *var* to "except" *exc* "as" *var*.  See
  **PEP 3110**.

* **PEP 3115**: 新たなメタクラスのシンタックス．以下の;

     class C:
         __metaclass__ = M
         ...

  代わりに次のようにしてください:

     class C(metaclass=M):
         ...

  モジュールグローバルの "__metaclass__" 変数はもうサポートされません
  。(これは "object" を派生しない全てのクラスのデフォルトを簡単に新ス
  タイルクラス化するための「松葉杖」でした。) (---訳注: 「新/旧スタイ
  ルクラス」は Python 2.x 固有の概念。Python 2.1 までの旧式クラスと、
  Python 2.2 で導入された、現在まで続く "object" を派生する (当時の旧
  からみた) 新スタイル。Python 2.2 から 2.7 では "class Clazz:" は (モ
  ジュールグローバルの "__metaclass__" を使わない限り) "object" を派生
  しない旧スタイルクラスでしたが、Python 3.x にはもはや「旧スタイルク
  ラス」がないのでこれは Python 2.2 から 2.7 での "class
  Clazz(object):" と同じ意味です。---)

* リスト内包表記はもう "[... for *var* in *item1*, *item2*, ...]" とい
  う構文形をサポートしません。代わりに "[... for *var* in (*item1*,
  *item2*, ...)]" を使用してください。また、リスト内包表記は異なるセマ
  ンティクスを持つことに注意してください。リスト内包表記は "list()" コ
  ンストラクタ内のジェネレータ式の糖衣構文に近く、特にループの制御変数
  はスコープ外ではもう使用することができません。

* *ellipsis* ("...") はどこででも原子的な式として使うことが出来ます。
  (以前はスライス内でのみ許されていました。) また、"..." と書かなけれ
  ば *ならなく* なりました。 (以前は文法の些細な偶然により ". . ." と
  書くことも出来ました。)


削除された操作
--------------

* **PEP 3113**: タプル引数のアンパックが削除されました.  "def foo(a,
  (b, c)): ..." のように書くことはできません。かわりに "def foo(a,
  b_c): b, c = b_c" を使用してください。

* バッククオートが削除されました (代わりに "repr()" を使用してください
  )。

* "<>" が削除されました (代わりに "!=" を使用してください)。

* 削除されたキーワード: "exec()" はキーワードでなくなりましたが、関数
  として残りました。 (幸運にも関数のシンタックスは 2.x でも許容されて
  います。)  また、 "exec()" はストリーム引数を受け取らなくなりました
  。"exec(f)" の代わりに "exec(f.read())" を使うことができます。

* "l" または "L" で終わる整数リテラルはサポートされません。

* "u" or "U" で始まる文字列リテラルはサポートされません。(---訳注: こ
  の "u"..."" は Python 3.3 で再び使えるようになりました。 ---)

* "from" *module* "import" "*" はモジュールレベルでのみ許され、関数内
  での使用は許されません。

* 相対インポートに許される構文は "from .[*module*] import *name*" のみ
  です。 "." で始まらない形の全ての "import" は絶対インポートと解釈さ
  れます。 (**PEP 328**)

* 古い形式のクラスはサポートされません。


Python 2.6 で既にあった変更
===========================

おそらく多くのユーザが一足飛びに Python 2.5 から Python 3.0 に移行しよ
うとするでしょうから、このセクションでは、もともとは Python 3.0 のため
にデザインされたものの Python 2.6 にバックポートされた新機能について、
読者に思い出してもらいましょう。 What's New in Python 2.6 内の対応する
セクションにはもっと長い説明が書かれています。

* PEP 343: "with" ステートメント. "with" 文は今では標準機能となったの
  で、 "__future__" からインポートする必要はもうありません。 コンテキ
  ストマネージャを書く と contextlib モジュール も見てください。

* PEP 366: メインモジュールからの明示的相対インポート. "-m" オプション
  の有用性を強化します。パッケージ内にあるモジュールを参照している際に
  関係します。

* PEP 370: ユーザごとの site-packages ディレクトリ.

* PEP 371: multiprocessing パッケージ.

* PEP 3101: 進化版文字列フォーマッティング. 注意: 2.6 の記述では
  "format()" メソッドが 8 ビット文字列と Unicode 文字列両方について述
  べていますが、3.0 では "str" 型 (Unicode サポートを持ったテキスト文
  字列) だけがこのメソッドをサポートしています。 "bytes" 型にはありま
  せん。計画では最終的にはこれだけが唯一の文字列フォーマットの API に
  なり、Python 3.1 では "%" 演算子は非推奨扱いを開始する予定です。(---
  訳注: "%" 演算子の撤廃は影響が大き過ぎるからか、現実には (ドキュメン
  トでの軽い記述を除き) 実行時に特別に非推奨扱いされることは 3.5 にな
  ってさえもいまだありません。 ---)

* PEP 3105: print を関数にする. これはもはや標準機能となったので、
  "__future__" からインポートする必要はありません。詳細はこのドキュメ
  ントの上の方に書いてあります。

* PEP 3110: 例外処理の変更.  The "except" *exc* "as" *var* syntax is
  now standard and "except" *exc*, *var* is no longer supported.  (Of
  course, the "as" *var* part is still optional.)

* PEP 3112: バイトリテラル. 文字列リテラル "b"..."" 表記 (とそのお仲間
  "b'...'", "b"""..."""", "br"..."" など) は今では "bytes" 型です。

* PEP 3116: 新しい I/O ライブラリ. "io" モジュールが今ではファイル I/O
  の標準手段です。組み込みの "open()" は今では "io.open()" へのエイリ
  アスであり、また、追加のキーワード引数 *encoding*, *errors*,
  *newline*, *closefd* を持ちます。不正な *mode* 引数で "IOError" では
  なく "ValueError" を投げるようになったことにも注意してください。テキ
  ストファイルオブジェクトの背後にあるバイナリファイルオブジェクトには
  、 "f.buffer" でアクセスできます。(ただしエンコーディング・デコーデ
  ィング操作の高速化のために、テキストオブジェクトは自身のバッファを保
  守管理していることに注意してください。)

* PEP 3118: 改訂版バッファプロトコル. 古いビルトインの "buffer()" は本
  当になくなりました; 新しいビルトイン "memoryview()" が (ほぼ) 同様の
  機能性を提供します。

* PEP 3119: 抽象基底クラス. "collections" モジュール内で定義されている
  "abc" モジュールと ABC 群が今では言語においてもっと目立った役割を演
  じるようになっていて、たとえば "dict" や "list" のようなビルトインの
  コレクション型はそれぞれ "collections.MutableMapping" と
  "collections.MutableSequence" の ABC に従うようになっています。

* PEP 3127: 整数リテラルのサポートと文法. 上述のとおり、新しい 8 進数
  リテラル表現だけが唯一の 8 進数リテラル表現となり、また、バイナリリ
  テラルが追加されました。

* PEP 3129: クラスデコレータ.

* PEP 3141: 数値の型階層. "numbers" が、もう一つの新しく ABC を使うモ
  ジュールで、Python の「数値塔 (numeric tower)」を定義しています。新
  しい "fractions" モジュールが "numbers.Rational" を実装していること
  にも注目してください。


ライブラリの変更
================

時間の制約により、この文書は標準ライブラリの非常に幅広い変更について徹
底的に取り上げてはいません。 ライブラリの大きな変更については **PEP
3108** を参照してください。 ここでは要約を示します:

* 多くの古いモジュールは削除されました。 "gopherlib" (もう使われません
  ) や "md5" ("hashlib" に代替されました) 等のいくつかのモジュールは
  **PEP 4** で既に廃止予定でした。 他のモジュールは、Irix、BeOS ならび
  に Mac OS 9 等のプラットフォームでのサポートが打ち切られた (**PEP
  11** 参照) ために削除されました。 いくつかのモジュールは使われなかっ
  たり、より良い代用品があるため Python 3.0 で削除されました 網羅的な
  リストは **PEP 3108** を参照してください。

* "bsddb3" パッケージが削除されました。テストの不安定性と Berkeley DB
  のリリーススケジュールにより、中心標準ライブラリでの存在がコア開発者
  の大きな負担になっていることが徐々に分かってきたためです。しかしなが
  ら "bsddb3" パッケージはまだ残っていて、
  https://www.jcea.es/programacion/pybsddb.htm で外部的に保守されてい
  ます。

* いくつかのモジュールは **PEP 8** に従っていないか、その他の理由によ
  り名前が変更されました:

  +-------------------------+-------------------------+
  | 以前の名前              | 新しい名前              |
  |=========================|=========================|
  | _winreg                 | winreg                  |
  +-------------------------+-------------------------+
  | ConfigParser            | configparser            |
  +-------------------------+-------------------------+
  | copy_reg                | copyreg                 |
  +-------------------------+-------------------------+
  | Queue                   | queue                   |
  +-------------------------+-------------------------+
  | SocketServer            | socketserver            |
  +-------------------------+-------------------------+
  | markupbase              | _markupbase             |
  +-------------------------+-------------------------+
  | repr                    | reprlib                 |
  +-------------------------+-------------------------+
  | test.test_support       | test.support            |
  +-------------------------+-------------------------+

* Python 2.x でのよくあるパターンは、ピュア Python で実装した版ととも
  に、オプショナルで、C 拡張として実装した「加速装置付き (accelerated)
  」版を持つ、というものです。例えば "pickle" と "cPickle" がそうです
  。それらモジュールの個々のユーザにとって、accelerated 版をインポート
  してみてダメならピュア Python 版を使う、というのも重荷となるものです
  。Python 3.0 では、 accelerated 版はピュア Python 版の実装の詳細と考
  えます。ユーザは常に標準バージョンをインポートすべきです。これ自身が
  accelerated 版のインポートを試みてダメならピュア Python 版を使うよう
  になっています。 "pickle" / "cPickle" のペアがこの対象になりました。
  "profile" モジュールは 3.1 でこれが予定されています。 "StringIO" モ
  ジュールは "io" モジュール内のクラスに変更されました。

* 関連のあるモジュールのいくつかはパッケージにまとめられ、ふつうサブモ
  ジュール名は単純化されました。結果として以下のようなパッケージが出来
  ました:

  * "dbm" ("anydbm", "dbhash", "dbm", "dumbdbm", "gdbm", "whichdb")。

  * "html" ("HTMLParser", "htmlentitydefs")。

  * "http" ("httplib", "BaseHTTPServer", "CGIHTTPServer",
    "SimpleHTTPServer", "Cookie", "cookielib")。

  * "tkinter" ("turtle" を除く全ての "Tkinter" 関連のモジュール)。
    "turtle" の対象読者は "tkinter" にそれほど関心がありません。 また
    、Python 2.6 以降では "turtle" の機能は大幅に向上しました。

  * "urllib" ("urllib", "urllib2", "urlparse", "robotparse")。

  * "xmlrpc" ("xmlrpclib", "DocXMLRPCServer", "SimpleXMLRPCServer")。

**PEP 3108** で取り上げられていない標準ライブラリーの他の変更:

* "sets" は廃止されました。組み込みの "set()" クラスを使用してください
  。

* "sys" モジュールの整理: "sys.exitfunc()", "sys.exc_clear()",
  "sys.exc_type", "sys.exc_value", "sys.exc_traceback" は削除されまし
  た。("sys.last_type" 等はまだあります。)

* "array.array" 型の整理: "read()" ならびに "write()" メソッドは廃止さ
  れました。代わりに "fromfile()" ならびに "tofile()" を使用してくださ
  い。また、array 向けの "'c'" タイプコードは廃止されました。バイトに
  は "'b'" 、Unicode 文字には "'u'" を使用してください。

* "operator" モジュールの整理: "sequenceIncludes()" および
  "isCallable()" は削除されました。

* "thread" モジュールの整理: "acquire_lock()" ならびに
  "release_lock()" は廃止されました。代わりに "acquire()" ならびに
  "release()" を使用してください。

* "random" モジュールの整理: "jumpahead()" API は削除されました。

* "new" モジュールは廃止されました。

* 関数 "os.tmpnam()"、"os.tempnam()" および "os.tmpfile()" は
  "tempfile" のため削除されました。

* "tokenize" モジュールはバイトでも機能するように変更されました。メイ
  ンのエントリポイントは generate_tokens から "tokenize.tokenize()" に
  なりました。

* "string.letters" and its friends ("string.lowercase" and
  "string.uppercase") are gone.  Use "string.ascii_letters" etc.
  instead.  (The reason for the removal is that "string.letters" and
  friends had locale-specific behavior, which is a bad idea for such
  attractively named global "constants".)

* モジュール "__builtin__" が "builtins" にリネームされました (アンダ
  ースコアの削除と 's' の追加)。 大半の大域名前空間における
  "__builtins__" 変数は変更されていません。 組み込みを変更するには
  "__builtins__" でなく "builtins" を使わなければなりません。


**PEP 3101**: 文字列整形の新たなアプローチ
==========================================

* 組み込みの新しい文字列書式化操作で、文字列の "%" 演算子を置き換える
  ものです。(しかしながら "%" 演算子はまだサポートされます; Python 3.1
  で非推奨となり、将来のいつかの時点で削除されます。) 完全な詳細は
  **PEP 3101** をお読み下さい。 (--- 訳注: Python 2.6 で既にあった変更
  での対応する記述に書いた訳注を参照。---)


例外に関する変更
================

例外の送出や捕捉を行う API は整理され、 強力な新機能が追加されました:

* **PEP 352**: 全ての例外は (直接的にまたは間接的に) "BaseException"
  を継承しなければなりません。 "BaseException" は例外階層の根です。 こ
  れは勧告としては新しくありませんが、"BaseException" 継承の *要求* は
  新しいです。 (Python 2.6 は依然として昔のクラスを送出するのを許容し
  ており、捕捉するものについての制限はありません。) 結果として文字列例
  外は終に本当の意味で、完全になくなりました。

* ほとんど全ての例外は、実際は "Exception" を継承すべきです。
  "BaseException" は最上位で扱われるべき例外、例えば "SystemExit" や
  "KeyboardInterrupt" の基底クラスとしてのみ使われるべきでしす。上記カ
  テゴリーを除く全ての例外を処理するのに推奨されるイディオムは
  "except" "Exception" です。

* "StandardError" は削除されました。

* 例外はシーケンスとして振る舞わなくなりました。代わりに "args" 属性を
  使用してください。

* **PEP 3109**: 例外の送出。 "raise *Exception*, *args*" ではなく
  "raise *Exception*(*args*)" としなければなりません。 加えて、トレー
  スバックを明示的に指定することはもう出来ません。 そう *しなければな
  らない* 場合は、代わりに "__traceback__" 属性に直接割り当てることが
  出来ます (下記参照).

* **PEP 3110**: 例外の捕捉。 "except *SomeException*, *variable*" では
  なく "except *SomeException* as *variable*" としなければなりません。
  その上 "except" ブロックがある場合 *variable* は明示的に削除されます
  。

* **PEP 3134**: 例外の連鎖。 暗黙の連鎖と明示的な連鎖の2つの場合があり
  ます。 暗黙の連鎖は例外が "except" や "finally" 処理ブロックで送出さ
  れたときに起こります。 この原因は大抵処理ブロック内のバグです。 これ
  を *二次的な (secondary)* 例外と呼びます。 この場合 (処理中の) 元々
  の例外は二次的な例外の "__context__" 属性に保存されます。 明示的な連
  鎖は以下の構文で起こします:

     raise SecondaryException() from primary_exception

  (*primary_exception* は例外オブジェクトを生成する任意の式です。たぶ
  んどこかで以前捕捉した例外でしょう。) 今の場合、一次的 (primary) な
  例外は二次的例外の "__cause__" 属性に保存されます。未捕捉の例外が起
  こった際に表示されるトレースバックは "__cause__" と "__context__" 属
  性を渡り歩き、そして一次的例外を一番上に置いて、連鎖のそれぞれの構成
  要素ごとにトレースバックを分けて表示します。(Java ユーザにはこの振る
  舞いは御馴染みでしょう。)

* **PEP 3134**: 例外オブジェクトがトレースバックを "__traceback__" 属
  性に格納するようになりました。 つまり、例外オブジェクトが例外関連の
  全情報を持つようになったということです。 "sys.exc_info()" を使う理由
  は (削除されていませんが) あまりありません。

* Windows が拡張モジュールのロードに失敗したときの例外メッセージが少し
  改善しました。 例えば、"error code 193" は "%1 is not a valid Win32
  application" になりました。 文字列は英語でないロケールを扱えるように
  なりました。


その他の変更
============


演算子と特殊メソッド
--------------------

* "!=" は "==" と逆の結果をかえします（"==" が "NotImplemented" を返さ
  なければ）。

* 「非束縛メソッド (unbound methods)」という概念は言語から削除されまし
  た。クラス属性としてのメソッドを参照しても今では普通の関数オブジェク
  トが得られます。

* "__getslice__()", "__setslice__()", "__delslice__()" はお亡くなりに
  なりました。構文 "a[i:j]" は今では "a.__getitem__(slice(i, j))" と解
  釈されます (または代入や削除で使われる場合は順に "__setitem__()" か
  "__delitem__()")。

* **PEP 3114**:  "next()" 標準メソッドは "__next__()" に改名されました
  。

* "__oct__()" ならびに "__hex__()" 特殊メソッドは削除されました。
  "oct()" ならびに "hex()" は "__index__()" を使って引数を整数に変換し
  ます。

* "__members__" と "__methods__" は削除されました。

* "func_X" 的な命名だった関数オブジェクトの属性が、 "__X__" 的命名に変
  わりました。ユーザ定義属性の命名を関数属性名前空間から解き放つためで
  す。つまり、 "func_closure", "func_code", "func_defaults",
  "func_dict", "func_doc", "func_globals", "func_name" が順に
  "__closure__", "__code__", "__defaults__", "__dict__", "__doc__",
  "__globals__", "__name__"

* "__nonzero__()" は "__bool__()" に改名されました。


組み込み
--------

* **PEP 3135**: 新しくなった "super()" 。今では "super()" は引数なしで
  呼び出せます。(これが "class" 内で定義される通常のインスタンスメソッ
  ド内であると仮定して) 正しいクラスとインスタンスが自動的に選択されま
  す。引数ありの場合の "super()" の振る舞いには変更はありません。

* **PEP 3111**: "raw_input()" が "input()" にリネームされました。つま
  り、新しい "input()" 関数は "sys.stdin" から行を読み、末尾の改行を取
  り除いて返します。入力が時期尚早に終わってしまったら "EOFError" にな
  ります。昔の "input()" の振る舞いが欲しければ "eval(input())" として
  ください。

* 新しい組み込み関数 "next()" が追加されました。 オブジェクトの
  "__next__()" メソッドを呼び出します。

* "round()" 関数の丸めの戦略と戻り値の型が変更されました。ど真ん中の場
  合に、四捨五入ではなく最近接偶数への丸めをするようになりました。(例
  えば "round(2.5)" は今では "2" を返します。 "3" ではなく。) (---訳注
  : 丸めモードについては Wikipedia 参照。---) "round(x[, n])" は常に浮
  動小数点数の結果を返す代わりに、 "x.__round__([n])" に処理を委譲する
  ようになりました。これは一般的に、単一引数で呼ばれた際に整数を返し、
  二つの引数で呼ばれた場合は "x" と同じ型の値として返します。

* "intern()" は "sys.intern()" に移動しました。

* "apply()" は削除されました。 "apply(f, args)" の代わりに "f(*args)"
  を使用してください。

* "callable()" は削除されました。 "callable(f)" のかわりに
  "isinstance(f, collections.Callable)" を使用してください。
  "operator.isCallable()" も削除されました。

* "coerce()" は削除されました。古い形式のクラスが削除されたため、この
  関数は必要ありません。

* "execfile()" は削除されました。 "execfile(fn)" の代わりに
  "exec(open(fn).read())" を使用してください。

* Removed the "file" type.  Use "open()".  There are now several
  different kinds of streams that open can return in the "io" module.

* "reduce()" は削除されました。もし本当に必要なら "functools.reduce()"
  を使用してください。ほぼ間違いなく "for" ループのほうがより可読性が
  高いでしょう。

* "reload()" は削除されました。  "imp.reload()" を使用してください。

* "dict.has_key()" は削除されました -- 代わりに "in" 演算子を使用して
  ください。


ビルドならびに C API の変更
===========================

時間がないため、以下のC APIへの変更点のリストは *かなり* 不完全です。

* Mac OS 9, BeOS, RISCOS, Irix, Tru64 に限らず、いくつものプラットフォ
  ームのサポートが打ち切られました。

* **PEP 3118**: 新たなバッファ API。

* **PEP 3121**: 例外モジュールの初期化と最終化

* **PEP 3123**: "PyObject_HEAD" を標準的な C に一致。

* 制限付き実行 の C API サポートはこれ以上されません。

* "PyNumber_Coerce()"、"PyNumber_CoerceEx()"、"PyMember_Get()"、および
  "PyMember_Set()" C APIs は削除されました。

* 新たな C API "PyImport_ImportModuleNoBlock()"、
  "PyImport_ImportModule()" のように動きますが、インポートロックでブロ
  ックしません (代わりにエラーを返します)。

* ブール変換の C 水準のスロットとメソッドがリネームされました:
  "nb_nonzero" が "nb_bool" になりました。

* C API から "METH_OLDARGS" と "WITH_CYCLE_GC" が削除されました。


性能
====

3.0 の可搬化 (generalization) による正味の結果は、Python 3.0 を
pystone ベンチマークすると Python 2.5 より 10% 遅くなる、というもので
した。これはどうやら小さい整数についての特殊処理を削除したことに一番大
きな要因があるようです。これには改善の余地がありますが、それは 3.0 リ
リース以降でしょう!


Python 3.0 への移植
===================

(---訳注: 今では独立したクックブック Python 2 から Python 3 への移植
があるのでそちらをご覧下さい。---) 既存の Python 2.5 や 2.6 のソースコ
ードを Python 3.0 に移植する最良の策は以下の通りです:

* (必須:) 優秀なテストカバレッジから始めてください。

* Python 2.6 に移植します。Python 2.x を Python 2.(x+1) に移植する普通
  の作業以上のことをしてはいけません。確実に全てのテストを通してくださ
  い。

* (まだ 2.6 を使います:) コマンドラインに "-3" オプションを渡します。
  これは 3.0 で削除された (または変更された) 機能についての警告発行を
  有効にします。再びテストスイートを実行して、そして警告が出たコードを
  それがなくなるまで修正し、全てのテストをパスさせます。

* "2to3" をあなたのソースコードツリーに対して走らせます (このツールの
  詳細については 2to3 --- Python 2 から 3 への自動コード変換 をみてく
  ださい)。Python 3.0 で変換結果のコードを走らせます。何か問題が残って
  いれば手動で修正し、修正後も全てのテストをパスするようにします。

Python 2.6 と 3.0 両方で変更なしに動作するコードを書こうとすることはお
奨め出来ません; それをするととても捻じ曲がったコーディングスタイルを使
う必要があるでしょう。例えば "print" やメタクラスを避けたりとかそんな
。Python 2.6 と 3.0 両バージョンともに対するサポートを必要とするライブ
ラリを保守しているのであれば、最良のアプローチは上記スリーステップを修
正して、2.6 版のソースコードを編集して "2to3" する、を繰り返すことです
。これは 3.0 版のソースコードを編集するより良いです。(---訳注: ここで
言っていることは正論なのですが、 "2to3" は「Python 3 では動くが Python
2 では動かない (かもしれない)」ものを生成します。2016 時点でも Python
2.7 はかなり元気 (予定では 2020 年までは公式にサポートされる) ですので
両バージョン (ただし今だと 2.7 と 3.2 以降) で変更なしで動作するものを
必要とすることは、残念ながらまだ多いでしょう (あなたが作っているのがラ
イブラリであるならば)。これについては Python 2 から Python 3 への移植
に少し書かれています。 ---)

C 拡張を Python 3.0 に移植するには、 Python 3 への拡張モジュール移植
を参照してください。
