Python 3.0の新機能—Pythonドキュメント

Python3.0の新機能

著者

グイドヴァンロッサム

この記事では、2.6と比較したPython3.0の新機能について説明します。 「Python3000」または「Py3K」としても知られるPython3.0は、意図的に後方互換性のない Pythonリリースとしては初めてです。 通常のリリースよりも多くの変更があり、すべてのPythonユーザーにとって重要な変更があります。 それでも、変更を消化した後、Pythonは実際にはそれほど変更されていないことがわかります。概して、よく知られている煩わしさや疣贅を修正し、多くの古いがらくたを削除しています。

この記事では、すべての新機能の完全な仕様を提供しようとはしていませんが、代わりに便利な概要を説明しようとしています。 詳細については、Python 3.0のドキュメント、および/またはテキストで参照されている多くのPEPを参照してください。 特定の機能の完全な実装と設計の根拠を理解したい場合、PEPには通常、通常のドキュメントよりも詳細な情報があります。 ただし、機能が完全に実装されると、通常、PEPは最新の状態に保たれないことに注意してください。

時間の制約により、このドキュメントは本来あるべきほど完全ではありません。 新しいリリースではいつものように、ソースディストリビューションのMisc/NEWSファイルには、変更されたすべての小さなことに関する豊富な詳細情報が含まれています。

一般的なつまずきのブロック

このセクションでは、Python 2.5に慣れている場合に、つまずく可能性が最も高いいくつかの変更をリストします。

印刷は機能です

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（）は、リストではなく「ビュー」を返します。 たとえば、これは機能しなくなりました：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（）は最短のシーケンスの終了時に停止します。 Python2.xの map（）と完全に互換性を持たせるには、シーケンスを itertools.zip_longest（）でラップします。 map(func, *sequences)はlist(map(func, itertools.zip_longest(*sequences)))になります。

• range（）は、任意のサイズの値で機能することを除いて、以前のxrange()と同じように動作するようになりました。 後者はもう存在しません。

• zip（）はイテレータを返すようになりました。

注文の比較

Python 3.0は、比較の順序付けのルールを簡素化しました。

• 順序比較演算子（<、<=、>=、>）は、オペランドに意味のある自然順序がない場合にTypeError例外を発生させます。 したがって、1 < 、0 > None、len <= lenなどの式は無効になります。たとえば、 None < Noneは、Falseを返す代わりに、 TypeError を発生させます。 当然の結果として、異種リストの並べ替えはもはや意味がありません。すべての要素が互いに比較可能でなければなりません。 これは、==および!=演算子には適用されないことに注意してください。異なるタイプの比較できないオブジェクトは、常に互いに等しくないように比較されます。
• builtin.sorted()および list.sort（）は、比較関数を提供する cmp 引数を受け入れなくなりました。 代わりに key 引数を使用してください。 NB key および reverse 引数が「キーワードのみ」になりました。
• cmp()関数はなくなったものとして扱われる必要があり、__cmp__()特殊メソッドはサポートされなくなりました。 __lt__()を使用して並べ替え、__eq__()と__hash__()を使用し、必要に応じてその他の豊富な比較を行います。 （cmp()機能が本当に必要な場合は、cmp(a, b)に相当する式(a > b) - (a < b)を使用できます。）

整数

• PEP 237 ：基本的に、longは int に名前が変更されました。 つまり、 int という名前の組み込み整数型は1つだけです。 ただし、ほとんどの場合、古いlongタイプと同じように動作します。
• PEP 238 ：1/2のような式はfloatを返します。 1//2を使用して、切り捨て動作を取得します。 （後者の構文は、少なくともPython 2.2以降、何年も前から存在しています。）
• sys.maxint定数は、整数の値に制限がなくなったため、削除されました。 ただし、 sys.maxsize は、実用的なリストまたは文字列インデックスよりも大きい整数として使用できます。 これは、実装の「自然な」整数サイズに準拠しており、通常、同じプラットフォーム上の以前のリリースのsys.maxintと同じです（同じビルドオプションを想定）。
• 長整数の repr（）には、末尾の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"..."リテラルを使用する必要があります。
• str 型と bytes 型は混在できないため、常に明示的に変換する必要があります。 str.encode（）を使用して str から bytes に移動し、 bytes.decode（）を使用して bytesから移動しますから str 。 bytes(s, encoding=...)とstr(b, encoding=...)をそれぞれ使用することもできます。
• str と同様に、 bytes タイプは不変です。 バッファリングされたバイナリデータを保持するための別の可変タイプ、 bytearray があります。 bytes を受け入れるほぼすべてのAPIは、 bytearray も受け入れます。 可変APIはcollections.MutableSequenceに基づいています。
• 生の文字列リテラルのすべての円記号は、文字通りに解釈されます。 これは、生の文字列の'\U'および'\u'エスケープが特別に扱われないことを意味します。 たとえば、Python3.0ではr'\u20ac'は6文字の文字列ですが、2.6ではur'\u20ac'は単一の「ユーロ」文字でした。 （もちろん、この変更は生の文字列リテラルにのみ影響します。Python3.0ではユーロ文字は'\u20ac'です。）
• 組み込みのbasestring抽象型は削除されました。 代わりに str を使用してください。 str 型と bytes 型には、共有基本クラスを保証するのに十分な共通の機能がありません。 2to3ツール（以下を参照）は、basestringのすべての出現箇所を str に置き換えます。
• テキストファイルとして開かれたファイル（ open（）のデフォルトモードのまま）は、常にエンコーディングを使用して、文字列（メモリ内）とバイト（ディスク上）の間をマッピングします。 バイナリファイル（mode引数にbを指定して開く）は、常にメモリ内のバイトを使用します。 つまり、ファイルが誤ったモードまたはエンコーディングを使用して開かれた場合、I / Oは、誤ったデータをサイレントに生成するのではなく、大音量で失敗する可能性があります。 また、Unixユーザーでさえ、ファイルを開くときに正しいモード（テキストまたはバイナリ）を指定する必要があることを意味します。 プラットフォームに依存するデフォルトのエンコーディングがあり、Unixyプラットフォームでは、LANG環境変数を使用して（場合によっては、他のプラットフォーム固有のロケール関連の環境変数を使用して）設定できます。 すべてではありませんが、多くの場合、システムのデフォルトはUTF-8です。 このデフォルトを当てにするべきではありません。 純粋なASCIIテキスト以外の読み取りまたは書き込みを行うアプリケーションには、おそらくエンコーディングをオーバーライドする方法が必要です。 codecs モジュールでエンコーディング対応ストリームを使用する必要はなくなりました。
• sys.stdin 、 sys.stdout 、 sys.stderr の初期値は、Unicodeのみのテキストファイルになりました（つまり、のインスタンスです）。 io.TextIOBase ）。 これらのストリームでバイトデータを読み書きするには、 io.TextIOBase.buffer 属性を使用する必要があります。
• ファイル名は、APIとの間で（Unicode）文字列として渡されたり返されたりします。 一部のプラットフォームではファイル名が任意のバイト文字列であるため、これはプラットフォーム固有の問題を引き起こす可能性があります。 （一方、Windowsでは、ファイル名はUnicodeとしてネイティブに保存されます。）回避策として、ほとんどのAPI（例： open（）および os モジュール内のファイル名を受け取る多くの関数は、文字列だけでなく bytes オブジェクトも受け入れます。また、いくつかのAPIには要求する方法があります。 バイトの戻り値。 したがって、 os.listdir（）は、引数が bytes インスタンスの場合、 bytes インスタンスのリストを返し、 os.getcwdb（）[X137X ]は、現在の作業ディレクトリを 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 を使用します。
• Python3.0用に更新された Unicode HOWTO も参照してください。

構文変更の概要

このセクションでは、Python3.0でのすべての構文の変更の概要を説明します。

新しい構文

• PEP 3107 ：関数の引数と戻り値の注釈。 これにより、関数のパラメーターと戻り値に注釈を付ける標準化された方法が提供されます。 __annotations__属性を使用して実行時にイントロスペクトできることを除いて、このようなアノテーションに付加されたセマンティクスはありません。 目的は、メタクラス、デコレータ、またはフレームワークを通じて実験を奨励することです。

• PEP 3102 ：キーワードのみの引数。 パラメータリストの*argsの後にある名前付きパラメータは、呼び出しでキーワード構文を使用して指定する必要があります。 パラメータリストで裸の*を使用して、可変長の引数リストを受け入れないが、キーワードのみの引数があることを示すこともできます。

• キーワード引数は、クラス定義の基本クラスのリストの後に許可されます。 これは、メタクラスを指定するための新しい規則（次のセクションを参照）によって使用されますが、メタクラスがサポートしている限り、他の目的にも使用できます。

• PEP 3104 ：非ローカルステートメント。 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]に設定されます。

• 辞書内包表記：{k: v for k, v in stuff}は、dict(stuff)と同じ意味ですが、より柔軟性があります。 （これは PEP 274 が立証されています。 :-)

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

• 新しい8進リテラル、例： 0o720（すでに2.6にあります）。 古い8進リテラル（0720）はなくなりました。

• 新しいバイナリリテラル、例： 0b1010（すでに2.6にあります）、そして新しい対応する組み込み関数 bin（）があります。

• バイトリテラルは、先頭にbまたはBが付いて導入され、対応する新しい組み込み関数 bytes（）があります。

構文の変更

• PEP 3109 および PEP 3134 ：新しい raise ステートメント構文：raise [expr [from expr]]。 下記参照。

• asと with は予約語になりました。 （2.6以降、実際には。）

• True、False、およびNoneは予約語です。 （2.6はすでにNoneの制限を部分的に実施しています。）

• except exc 、 var からexcept exc as var に変更します。 ]。 PEP 3110 を参照してください。

• PEP 3115 ：新しいメタクラス構文。 それ以外の：

  class C:
      __metaclass__ = M
      ...

  ここで使用する必要があります：

  class C(metaclass=M):
      ...

  module-global __metaclass__変数はサポートされなくなりました。 （オブジェクトからすべてのクラスを派生させることなく、新しいスタイルのクラスにデフォルト設定するのを簡単にするのは松葉杖でした。）

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

• 省略記号（...）は、どこでもアトミック式として使用できます。 （以前はスライスでのみ許可されていました。）また、は...のスペルである必要があります。 （以前は、文法の単なる偶然によって、. . .と綴ることもできました。）

削除された構文

• 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またはUをサポートしなくなりました。
• from module import *構文は、モジュールレベルでのみ許可され、関数内では許可されなくなりました。
• 相対インポートで受け入れられる構文はfrom .[module] import nameのみです。 .で始まらないすべての import フォームは、絶対インポートとして解釈されます。 （ PEP 328 ）
• クラシッククラスはなくなりました。

Python2.6にすでに存在する変更

多くのユーザーはおそらくPython2.5からPython3.0に直接ジャンプするため、このセクションでは、元々Python 3.0用に設計されたが、Python2.6にバックポートされた新機能を読者に思い出させます。 詳細については、 Python 2.6 の新機能の対応するセクションを参照してください。

• PEP 343：「with」ステートメント。 with ステートメントが標準機能になり、 __ future __ からインポートする必要がなくなりました。 Writing Context Managers と contextlibモジュールもチェックしてください。
• PEP 366：メインモジュールからの明示的な相対インポート。 これにより、参照されるモジュールがパッケージ内にある場合の -m オプションの有用性が高まります。
• PEP 370：ユーザーごとのサイトパッケージディレクトリ。
• PEP 371：マルチプロセッシングパッケージ。
• PEP 3101：高度な文字列フォーマット。 注：2.6の説明では、8ビット文字列とUnicode文字列の両方の format（）メソッドについて説明しています。 3.0では、 str タイプ（Unicodeをサポートするテキスト文字列）のみがこのメソッドをサポートします。 bytes タイプはそうではありません。 最終的には、これを文字列フォーマット用の唯一のAPIにし、Python3.1で%演算子の非推奨を開始する予定です。
• PEP 3105：関数として印刷。 これは現在標準機能であり、 __ future __ からインポートする必要はありません。 詳細は上記のとおりです。
• PEP 3110：例外処理の変更。 exception exc as 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 が追加されました。 、改行および closefd 。 また、無効な mode 引数は、 IOError ではなく、 ValueError を発生させることに注意してください。 テキストファイルオブジェクトの基になるバイナリファイルオブジェクトには、f.bufferとしてアクセスできます（ただし、エンコードおよびデコード操作を高速化するために、テキストオブジェクトはそれ自体のバッファを維持することに注意してください）。
• PEP 3118：改訂されたバッファプロトコル。 古い組み込みのbuffer()は実際になくなりました。 新しい組み込みの memoryview（）は、（ほとんど）同様の機能を提供します。
• PEP 3119：抽象基本クラス。 abc モジュールとコレクションモジュールで定義されたABCは、現在この言語でやや重要な役割を果たしており、 dict や[ X191X] list は、それぞれcollections.MutableMappingおよびcollections.MutableSequence ABCに準拠しています。
• PEP 3127：整数リテラルのサポートと構文。 上記のように、サポートされているのは新しい8進リテラル表記のみであり、バイナリリテラルが追加されています。
• PEP 3129：クラスデコレータ。
• PEP 3141：数値のタイプ階層。 numbers モジュールは、Pythonの「数値タワー」を定義するABCのもう1つの新しい使用法です。 また、 numbers.Rational を実装する新しい fractions モジュールにも注意してください。

ライブラリの変更

時間の制約があるため、このドキュメントでは、標準ライブラリに対する非常に広範な変更については網羅していません。 PEP 3108 は、ライブラリへの主要な変更のリファレンスです。 これがカプセルレビューです：

• 多くの古いモジュールが削除されました。 gopherlib（現在は使用されていません）やmd5（ hashlib に置き換えられました）などの一部は、 PEP 4 によってすでに非推奨になっています。 ]。 Irix、BeOS、Mac OS 9などのさまざまなプラットフォームのサポートが削除された結果、その他のものは削除されました（ PEP 11 を参照）。 一部のモジュールは、使用されていないため、またはより適切な代替品が存在するため、Python3.0で削除するために選択されました。 完全なリストについては、 PEP 3108 を参照してください。

• bsddb3パッケージは、テストの不安定性とBerkeley DBのリリーススケジュールにより、コア標準ライブラリに存在することがコア開発者にとって特に負担になることが判明したため、削除されました。 ただし、パッケージは正常に機能しており、 https://www.jcea.es/programacion/pybsddb.htmで外部的に管理されています。

• 一部のモジュールは、古い名前が PEP 8 に従わなかったため、またはその他のさまざまな理由で名前が変更されました。 リストは次のとおりです。

  旧名	新しい名前
  _winreg	winreg
  ConfigParser	configparser
  copy_reg	copyreg
  列	列
  SocketServer	ソケットサーバー
  markupbase	_markupbase
  repr	reprlib
  test.test_support	test.support

• Python 2.xの一般的なパターンは、モジュールの1つのバージョンを純粋なPythonで実装し、オプションの高速化バージョンをC拡張として実装することです。 たとえば、 pickle およびcPickleです。 これにより、これらのモジュールの各ユーザーで、高速化されたバージョンをインポートし、純粋なPythonバージョンにフォールバックするという負担がかかります。 Python 3.0では、高速化されたバージョンは、純粋なPythonバージョンの実装の詳細と見なされます。 ユーザーは常に標準バージョンをインポートする必要があります。標準バージョンは、高速化されたバージョンをインポートしようとし、純粋なPythonバージョンにフォールバックします。 ピクル / 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()を使用してください。 また、配列の'c'タイプコードはなくなりました。バイトの場合は'b'を使用し、Unicode文字の場合は'u'を使用してください。
• 演算子モジュールのクリーンアップ：sequenceIncludes()およびisCallable()を削除しました。
• threadモジュールのクリーンアップ：acquire_lock()およびrelease_lock()はなくなりました。 代わりにacquire()とrelease()を使用してください。
• ランダムモジュールのクリーンアップ：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__ではなく、ビルトインを使用する必要があります。

PEP 3101 ：文字列フォーマットへの新しいアプローチ

• 組み込みの文字列フォーマット操作用の新しいシステムは、%文字列フォーマット演算子に置き換わるものです。 （ただし、%演算子は引き続きサポートされています。これは、Python 3.1で非推奨になり、後で言語から削除されます。） PEP 3101 を読んでください。フルスクープ。

例外の変更

例外を発生させてキャッチするためのAPIがクリーンアップされ、新しい強力な機能が追加されました。

• PEP 352 ：すべての例外は BaseException から（直接的または間接的に）派生する必要があります。 これは、例外階層のルートです。 これは推奨事項としては新しいものではありませんが、 BaseException から継承する要件は新しいものです。 （Python 2.6では、引き続きクラシッククラスを発生させることができ、キャッチできるものに制限はありませんでした。）結果として、文字列例外は最終的に完全に無効になります。

• ほとんどすべての例外は、実際には Exception から派生する必要があります。 BaseException は、 SystemExit や KeyboardInterrupt など、トップレベルでのみ処理する必要がある例外の基本クラスとしてのみ使用する必要があります。 この後者のカテゴリを除くすべての例外を処理するための推奨イディオムは、 exception Exception を使用することです。

• StandardErrorは削除されました。

• 例外はシーケンスとして動作しなくなりました。 代わりにargs属性を使用してください。

• PEP 3109 ：例外を発生させます。 raise Exception, argsの代わりにraise Exception(args)を使用する必要があります。 さらに、トレースバックを明示的に指定することはできなくなりました。 代わりに、これを行うためにがを持っている場合は、__traceback__属性に直接割り当てることができます（以下を参照）。

• PEP 3110 ：例外をキャッチします。 except SomeException, variableの代わりにexcept SomeException as variableを使用する必要があります。 さらに、変数は、 exception ブロックが残っている場合に明示的に削除されます。

• PEP 3134 ：例外チェーン。 暗黙的な連鎖と明示的な連鎖の2つのケースがあります。 exception または finally ハンドラブロックで例外が発生すると、暗黙的な連鎖が発生します。 これは通常、ハンドラブロックのバグが原因で発生します。 これをセカンダリ例外と呼びます。 この場合、（処理されていた）元の例外は、2次例外の__context__属性として保存されます。 明示的な連鎖は、次の構文で呼び出されます。

  raise SecondaryException() from primary_exception

  （ここで、 primary_exception は、例外オブジェクト、おそらく以前にキャッチされた例外を生成する式です）。 この場合、一次例外は二次例外の__cause__属性に格納されます。 未処理の例外が発生したときに出力されるトレースバックは、__cause__属性と__context__属性のチェーンをウォークし、チェーンのコンポーネントごとに個別のトレースバックを出力します。 （Javaユーザーはこの動作を認識する可能性があります。）

• PEP 3134 ：例外オブジェクトは、トレースバックを__traceback__属性として保存するようになりました。 これは、例外オブジェクトに例外に関連するすべての情報が含まれるようになり、 sys.exc_info（）を使用する理由が少なくなることを意味します（後者は削除されません）。

• Windowsが拡張モジュールのロードに失敗した場合、いくつかの例外メッセージが改善されます。 たとえば、error code 193は%1 is not a valid Win32 applicationになりました。 文字列は英語以外のロケールを処理するようになりました。

その他その他の変更

演算子と特別なメソッド

• !=は、==が NotImplemented を返さない限り、==の反対を返すようになりました。
• 「非バインドメソッド」の概念は言語から削除されました。 メソッドをクラス属性として参照すると、プレーンな関数オブジェクトが得られるようになりました。
• __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、 [X78X ]は__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)は3ではなく2を返すようになりました。）round(x[, n])は、常にフロートを返すのではなく、x.__round__([n])に委任するようになりました。 通常、単一の引数で呼び出された場合は整数を返し、2つの引数で呼び出された場合は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())を使用してください。
• fileタイプを削除しました。 open（）を使用します。 io モジュールで開くことができる、いくつかの異なる種類のストリームがあります。
• reduce()を削除しました。 本当に必要な場合は、 functools.reduce（）を使用してください。 ただし、99％の場合、明示的な for ループの方が読みやすくなります。
• reload()を削除しました。 imp.reload（）を使用します。
• NS。 dict.has_key() –代わりに in 演算子を使用してください。

ビルドとCAPIの変更

時間の制約により、CAPIへの変更の非常に不完全なリストを次に示します。

• Mac OS 9、BeOS、RISCOS、Irix、Tru64など、いくつかのプラットフォームのサポートが終了しました。
• PEP 3118 ：新しいバッファーAPI。
• PEP 3121 ：拡張モジュールの初期化とファイナライズ。
• PEP 3123 ： PyObject_HEAD を標準Cに準拠させます。
• 制限された実行に対するCAPIサポートはなくなりました。
• PyNumber_Coerce()、PyNumber_CoerceEx()、PyMember_Get()、およびPyMember_Set() CAPIが削除されました。
• 新しいCAPI PyImport_ImportModuleNoBlock（）は、 PyImport_ImportModule（）と同様に機能しますが、インポートロックでブロックされません（代わりにエラーを返します）。
• ブール変換の経営幹部レベルのスロットとメソッドの名前が変更されました。nb_nonzeroはnb_boolになりました。
• CAPIからMETH_OLDARGSとWITH_CYCLE_GCを削除しました。

パフォーマンス

3.0の一般化の最終的な結果は、Python3.0がPython2.5よりも約10 % s低いpystoneベンチマークを実行することです。 おそらく最大の原因は、小さな整数の特殊ケーシングの削除です。 改善の余地はありますが、3.0がリリースされた後に起こります！

Python3.0への移植

既存のPython2.5または2.6ソースコードをPython3.0に移植するための最善の戦略は、次のとおりです。

0. （前提条件:)優れたテストカバレッジから始めます。

1. Python2.6への移植。 これは、Python2.xからPython2。（x + 1）への平均的なポートよりも多くの作業ではありません。 すべてのテストに合格することを確認してください。

2. （まだ2.6を使用しています:) -3コマンドラインスイッチをオンにします。 これにより、3.0で削除（または変更）される機能に関する警告が有効になります。 テストスイートを再度実行し、警告がなくなるまで警告が表示されるコードを修正し、すべてのテストに合格します。

3. 2to3ソースからソースへのトランスレータをソースコードツリー上で実行します。 （このツールの詳細については、 2to3-自動化されたPython2から3のコード変換を参照してください。）Python3.0で変換の結果を実行します。 残りの問題を手動で修正し、すべてのテストに再度合格するまで問題を修正します。

Python2.6と3.0の両方で変更なしで実行されるソースコードを作成することはお勧めしません。 非常にゆがんだコーディングスタイルを使用する必要があります。 printステートメント、メタクラスなどを回避します。 Python2.6とPython3.0の両方をサポートする必要があるライブラリを維持している場合、最善のアプローチは、編集するのではなく、ソースコードの2.6バージョンを編集し、2to3トランスレータを再度実行して、上記の手順3を変更することです。ソースコードの3.0バージョン。

C拡張機能をPython3.0に移植する方法については、拡張モジュールのPython 3への移植を参照してください。