What’s New In Python 3.0¶
著者: | Guido van Rossum |
---|
この記事では 2.6 と比較した Python 3.0 での新機能を解説します。 Python 3.0、あるいは "Python 3000"、 "Py3K" は初めて 意図的に後方非互換にした Python のリリースです。 通常のリリースよりも多くの変更があり、全ての Python ユーザにとって重要です。 しかし、変更について理解したら Python に実際にはそれほど変更がないことが分かるでしょう。 全体的に見れば、よく知られた悩みの種が概ね解決され、昔の粗雑なものが取り除かれています。
この記事は全ての新機能を完璧な仕様を示そうとはしませんが、便利な概要については説明しようとしています。 全詳細については 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="")
which produces:
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: Essentially,
long
renamed toint
. That is, there is only one built-in integral type, namedint
; but it behaves mostly like the oldlong
type. - PEP 238: An expression like
1/2
returns a float. Use1//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: キーワードオンリー (keyword-only) 引数。パラメータリスト中で
*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
文。nonlocal x
を使うと外側の (ただしグローバルでない) スコープから、直接変数を代入することが出来るようになります。nonlocal
は新しく予約語になりました。PEP 3132: 拡張されたイテレータのアンパッキング。
a, b, *rest = some_sequence
のようなことを書けるようになりました。*rest, a = stuff
も出来ます。rest
オブジェクトは常に (空かもしれなくても) リストです; 右辺には任意のイテラブルを置けます。例えば:(a, *rest, b) = range(5)
これは a に
0
を、 b に4
を、そして rest に[1, 2, 3]
をセットします。Dictionary comprehensions:
{k: v for k, v in stuff}
means the same thing asdict(stuff)
but is more flexible. (This is PEP 274 vindicated. :-)セットリテラル、例えば
{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]]
。以下を参照してください。True
、False
、およびNone
が予約語になりました。(2.6 では既にNone
が部分的に制限されていました)except
exc, var からexcept
excas
var に変更されました。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
orU
で始まる文字列リテラルはサポートされません。(—訳注: このu"..."
は Python 3.3 で再び使えるようになりました。 —)from
moduleimport
*
はモジュールレベルでのみ許され、関数内での使用は許されません。- The only acceptable syntax for relative imports is
from .[module] import name
. Allimport
forms not starting with.
are interpreted as absolute imports. (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: 例外処理の変更.
except
excas
var 構文が標準となり、except
exc, var はもうサポートされません。(もちろんas
var 部分は今でも省略可能です。) - 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 を参照してください。 ここでは要約を示します:
Many old modules were removed. Some, like
gopherlib
(no longer used) andmd5
(replaced byhashlib
), were already deprecated by PEP 4. Others were removed as a result of the removal of support for various platforms such as Irix, BeOS and Mac OS 9 (see PEP 11). Some modules were also selected for removal in Python 3.0 due to lack of use or because a better replacement exists. See PEP 3108 for an exhaustive list.bsddb3
パッケージが削除されました。テストの不安定性と Berkeley DB のリリーススケジュールにより、中心標準ライブラリでの存在が中心開発者の大きな負担になっていることが徐々に分かってきたためです。しかしながらbsddb3
パッケージはまだ残っていて、https://www.jcea.es/programacion/pybsddb.htm で外部的に保守されています。Some modules were renamed because their old name disobeyed PEP 8, or for various other reasons. Here’s the list:
以前の名前 新しい名前 _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
とその仲間 (string.lowercase
とstring.uppercase
) は廃止されました。代わりにstring.ascii_letters
等を使用してください。(削除された理由はstring.letters
とその仲間にロケール固有の挙動があったためです。そのようなものに対して、いつでも使えそうな "定数" として魅力的に名付けるのは良い考えとは言えません。)- モジュール
__builtin__
がbuiltins
にリネームされました (アンダースコアの削除と 's' の追加)。 大半の大域名前空間における__builtins__
変数は変更されていません。 組み込みを変更するには__builtins__
でなくbuiltins
を使わなければなりません。
PEP 3101: 文字列整形の新たなアプローチ¶
- 組み込みの新しい文字列書式化操作で、文字列の
%
演算子を置き換えるものです。(しかしながら%
演算子はまだサポートされます; Python 3.1 で非推奨となり、将来のいつかの時点で削除されます。) 完全な詳細は PEP 3101 をお読み下さい。 (— 訳注: Python 2.6 で既にあった変更 での対応する記述に書いた訳注を参照。—)
例外に関する変更¶
例外の送出や捕捉を行う API は整理され、 強力な新機能が追加されました:
PEP 352: All exceptions must be derived (directly or indirectly) from
BaseException
. This is the root of the exception hierarchy. This is not new as a recommendation, but the requirement to inherit fromBaseException
is new. (Python 2.6 still allowed classic classes to be raised, and placed no restriction on what you can catch.) As a consequence, string exceptions are finally truly and utterly dead.ほとんど全ての例外は、実際は
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__
は削除されました。- The function attributes named
func_X
have been renamed to use the__X__
form, freeing up these names in the function attribute namespace for user-defined attributes. To wit,func_closure
,func_code
,func_defaults
,func_dict
,func_doc
,func_globals
,func_name
were renamed to__closure__
,__code__
,__defaults__
,__dict__
,__doc__
,__globals__
,__name__
, respectively. __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. Useopen()
. There are now several different kinds of streams that open can return in theio
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) に移植する普通の作業以上のことをしてはいけません。確実に全てのテストを通してください。
- (Still using 2.6:) Turn on the
-3
command line switch. This enables warnings about features that will be removed (or change) in 3.0. Run your test suite again, and fix code that you get warnings about until there are no warnings left, and all your tests still pass. 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 への拡張モジュール移植 を参照してください。