TSpython 発言

　ということで、後半、ようやくアップできます。

※昨日学校が無かったので、一日がかりでした。

　チェック終わりしだい、全文をWikiにアップします
ので、そこでの修正もあればお願いいたします。

＜つづき＞

* Set literals, eg {1, 2} .
* {1, 2}のような集合リテラル

Note that {} is an empty dictionary; use set() for an empty set.
注意：{}は空の辞書のリテラルです。空の集合には、『set()』を使ってください。

Set comprehensions are also supported; eg, {x for x in stuff} means the same thing as set(stuff) but is more flexible. 
集合の内包記法もサポートされています。
例：
	{x for x in stuff}
は
	set(stuff)
と同等ですが、より柔軟です

* New octal literals, eg 0o720 (already in 2.6).
* 新しい8進数のリテラルは、『0o720』のように書きます（既に2.6では使えます）

The old octal literals ( 0720 ) are gone.
これまでの8進数のリテラル『0720』はなくなっています。

（訳注：以前のPythonでは、先頭に０がくる整数は８進法表記となっていた）

* New binary literals, eg 0b1010 (already in 2.6), and there is a new corresponding builtin function, bin() .
* 『0b1010』のような新しい二進法リテラル、（既に2.6では使えます）は新しい組み込み関数であるbin関数に対応します。

* Bytes literals are introduced with a leading b or B , and there is a new corresponding builtin function, bytes() .
* byte列のリテラルは'b'か'B'を先頭につけます。そして新しい対応する組み込み関数は、bytes関数です。 

（訳注：バイト列のリテラルはb'\x01\x02'やb'abc'のように書きます）

Changed Syntax
変更された構文

* PEP 3109 and PEP 3134 : new raise statement syntax: raise [expr [from expr ]] .

* PEP 3109とPEP 3134 : 新しいraise文の構文：raise [expr [from expr]]

See below.
下記参照してください。

* as and with are now reserved words.(Since 2.6, actually.)
* 『as』と『with』が新しく予約語になりました（実際は2.6から）

True , False , and None are reserved words.(2.6 partially enforced the restrictions on None already.)
『True』と『False』及び『None』は予約語です（すでに『None』についての制限は、2.6では部分的に実施されています）

* Change from except exc , var to except exc as var .See PEP 3110
『except exec, var』が『except exc as var』という書きかたに変更されました。PEP 3110参照のこと。

* PEP 3115 : New Metaclass Syntax.Instead of:
	class C:
		__metaclass__ = M
		... 
you must now use:
	class C (metaclass = M):
		... ... 

* PEP 3115 : 新メタクラス構文。
	class C:
		__metaclass__ = M
		... 
の代りに、
	class C (metaclass = M):
		... ... 
を使って下さい。

The module-global __metaclass__ variable is no longer supported.
モジュール全体で使える__metaclass__変数は、もはやサポートされていません。 

(It was a crutch to make it easier to default to new-style classes without deriving every class from object .)
(__metaclass__変数は、『object』からすべてのクラスを派生させずに、新スタイルのクラスを容易にデフォルトにするための補助でした）

* List comprehensions no longer support the syntactic form [... for var in item1 , item2 , ...] .
* リスト内包記法はもはや
	[... for var in item1 , item2 , ...] 
という書きかたをサポートしていません。

Use [... for var in ( item1 , item2 , ...)] instead. 
代わりに
	[... for var in ( item1 , item2 , ...)]
を使用してください。

Also note that list comprehensions have different semantics: 
they are closer to syntactic sugar for a generator expression inside a list() constructor, and in particular the loop control variables are no longer leaked into the surrounding scope.
また、リスト内包表現は別の意味を持つことに気をつけてください。これらはリストのコンストラクタとしてジェネレータ式を用いることを終わらせる構文糖衣です。そして、個々のループを制御する変数は、もはや周囲のスコープに漏れません。

（訳注：2.xに於けるリストの内包記法で用いられる変数（例えば『[x for x in range(10)]のx』は、リストの外にも影響を与えていた。しかしジェネレータ式はローカル変数として扱われていた。そのため、外部の変数に影響を与えないため、次のような裏技が用いられていた。

《Python 2.x》
>>> x = 100
>>> [x for x in range(10)] # リストの内包記法
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
>>> x
9	←変数xの内容が変更されている
>>> x = 100
>>> (x for x in range(10)) # ジェネレータの内包記法
<generator object at 0x4031362c>
>>> x
100	←変数xの内容が変更されていない
>>> list(x for x in range(10)) # ジェネレータの内包記法とlist関数(listクラスのコンストラクタ）
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
>>> x
100	←変数xの内容が変更されていない

　しかし、Python 3.0ではリスト内包記法の変数もローカルとして扱われるため、上記のような小手先の技は必要なくなった

《Python 3.0》
>>> x = 100
>>> [x for x in range(10)]
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
>>> x
100
>>>
）

* The ellipsis ( ... ) can be used as an atomic expression anywhere.
* 省略記号『...』は、アトム表現としてどこでも使うことができます。

 (Previously it was only allowed in slices.) Also, it must now be spelled as ... . 
（以前はスライスのみで許可された。 ）また、現在のスペルする必要があります... 。 

(Previously it could also be spelled as . . . , by a mere accident of the grammar.)
（以前にも、スペルかもしれない。 。 。 。 。 は 、文法のは単なる偶然。 ） 

Removed Syntax
削除された構文

* PEP 3113 : Tuple parameter unpacking removed.
* PEP 3113 : 『タプルパラメータの展開』を削除

You can no longer write def foo(a, (b, c)): ... . Use def foo(a, b_c): b, c = b_c instead.
def foo(a, (b, c)):
	...
……という書きかたは、もはや使えません。代わりに
def foo(a, b_c):
	b, c = b_cなどとして下さい

* Removed backticks (use repr() instead).
* バックティック(backticks)は削除されました（代わりにrepr関数を使用してください）

（訳注：おそらくバッククォート『`』による評価のことと思われる。『`expr`』は『repr(expr)』の略記として使えたが、3.0から使えなくなった）

* Removed <> (use != instead).
* 『<>』は削除されました。代わりに『!=』を使用してください

* Removed keyword: exec() is no longer a keyword; it remains as a function.
* 予約語の削除。『exec』はもうすでに予約語ではなく、exec関数として残っている。

（訳注：原文では『キーワード(keyword)』と書かれているが、『予約語(reserved word)』の誤りと思われる。Pythonでは、キーワードは、引数などを指定する名前（キーワード引数）などに使われ、他の言語のように予約語の意味として使われることはほｔんどない）

(Fortunately the function syntax was also accepted in 2.x.)
（幸いにも、この関数構文は既に2.xで受け入れられています）

Also note that exec() no longer takes a stream argument; instead of exec(f) you can use exec(f.read()) .
さらに注意すべきは、exec関数はもうすでにストリーム（引数）には使えません。
exec(f)とする代わりに、exec(f.read())を利用してください。

* Integer literals no longer support a trailing l or L .
* 整数リテラルでは、もはや末尾の'l'または'L'はサポートされません。

（訳注：前述の通り、ロング整数型は整数型に統合された）

* String literals no longer support a leading u or U .
* 文字列リテラルでは、もはや『u'...'』や『U'...'』はサポートされません。

（訳注：前述の通り、Unicode文字列はstrに統合された）

* The from module import * syntax is only allowed at the module level, no longer inside functions.
* 『from module import *』構文は、モジュールレベルのみ許可されます。もはや関数の中では使えません。

* The only acceptable syntax for relative imports is from .[ module ] import name .
* 相対importとして許されるのは、『from .[module] import name』だけです。

（※相対import(rerative import)は、モジュール階層を辿ってインポートするための構文）

All import forms not starting with . are interpreted as absolute imports.(PEP 0328)
『.』から始まらない全てのimportは、絶対importとして解釈されます。(PEP 0328)

* Classic classes are gone.
* 旧スタイルのクラスはなくなりました。


Changes Already Present In Python 2.6
Python 2.6 において既に提示された変更

Since many users presumably make the jump straight from Python 2.5 to Python 3.0, this section reminds the reader of new features that were originally designed for Python 3.0 but that were back-ported to Python 2.6.
多くのユーザがたぶんPython2.5からPython3.0に直接移行する（と思われる）ので、このセクションは、本来Python3.0のためにデザインされた新機能が、Python2.6に逆移植されたように感じるでしょう。

The corresponding sections in What’s New in Python 2.6 should be consulted for longer descriptions.
Python2.6中の新着情報の中の対応するセクションには、より詳細な説明があります。

* PEP 343: The ‘with’ statement.
* PEP 343: with文

The with statement is now a standard feature and no longer needs to be imported from the __future__ .
with文が普通に使えるようになりました。もう『__future__』をimportする必要はありません。

Also check out Writing Context Managers and The contextlib module .
また、『Writing Context Managers』と『contextlib』モジュールについてもチェックしてみてください。

* PEP 366: Explicit Relative Imports From a Main Module . 
* PEP 366: メインモジュールからの明示的な相対import

This enhances the usefulness of the -m option when the referenced module lives in a package.
これは、パッケージの中に参照モジュールが存在している場合、 -mオプションの有用性を高めます。

* PEP 370: Per-user site-packages Directory .
* PEP 370: ユーザーごとのsiteパッケージのディレクトリ。

* PEP 371: The multiprocessing Package.
* PEP 371：マルチプロセッシングパッケージ

* PEP 3101: Advanced String Formatting . 
* PEP 3101: 拡張された文字列フォーマット

Note: the 2.6 description mentions the format() method for both 8-bit and Unicode strings.
注意：2.6版の解説は、8ビットとUnicodeの文字列の両方のためのformat()メソッドに言及しています。

In 3.0, only the str type (text strings with Unicode support) supports this method; the bytes type does not. 
3.0では、このメソッドはstr型(Unicodeによるテキスト文字列)のみをサポートします。bytes型はサポートしません。

The plan is to eventually make this the only API for string formatting, and to start deprecating the % operator in Python 3.1.
この計画は、最終的にはこの方法を文字列フォーマットの唯一のAPIとし、%演算子（の使用）をPython 3.1から非使用を訴えることを始めます。

* PEP 3105: print As a Function . 
* PEP 3105: print文は関数のように（扱ってください）

This is now a standard feature and no longer needs to be imported from __future__ .
この方式は今や標準になりました。もはや『__future__』をimportする必要はありません。

More details were given above.
詳細はすでに上記で説明済みです。

* PEP 3110: Exception-Handling Changes . 
* PEP 3110: 例外処理の変更

The except exc as var syntax is now standard and except exc , var is no longer supported.
『except exc as var』構文は、今や標準になりました。『except exc, var』構文はすでにサポートされていません。

(Of course, the as var part is still optional.)
（もちろん、『as ver』の部分は省略可能です）

* PEP 3112: Byte Literals . 
* PEP 3112: バイト列リテラル

The b"..." string literal notation (and its variants like b'...' , b"""...""" , and br"..." ) now produces a literal of type bytes .
『b"..."』文字列リテラル表記(そして、b'...',b"""...""",あるいはbr"..."のようなバリエーションの表記）は、今やbytes型オブジェクトを生み出すリテラルです。

* PEP 3116: New I/O Library. 
* PEP 3116: 新しいI/Oライブラリ

The io module is now the standard way of doing file I/O, and the initial values of sys.stdin , sys.stdout and sys.stderr are now instances of io.TextIOBase .
ioモジュールは今やファイルI/Oを行う標準的な方法であり、sys.stdinやsys.stdout、そしてsys.stderrorの初期値は、今やio.TextIOBaseのインスタンスです。

The builtin open() function is now an alias for io.open() and has additional keyword arguments encoding , errors , newline and closefd .
組み込みのopen関数は、今やio.openのエイリアスであり、encoding、errors、newline、closefdなどのキーワード引数が追加されました。

Also note that an invalid mode argument now raises ValueError , not IOError .
また、無効なモード引数は、今やIOErrorではなくValueErrorを発生させます。

The binary file object underlying a text file object can be accessed as f.buffer 

(but beware that the text object maintains a buffer of itself in order to speed up the encoding and decoding operations). 
テキストファイルオブジェクトを基礎とするバイナリファイルオブジェクトは、『f.buffer』としてアクセスできます（ただし、エンコーディング操作やデコーディング操作のスピードアップのために、テキストオブジェクトが、そのもののバッファを維持するよう気をつけてください）

* PEP 3118: Revised Buffer Protocol . 
* PEP 3118: 改訂バッファプロトコル

The old builtin buffer() is now really gone; the new builtin memoryview() provides (mostly) similar functionality.
古いbuffer関数は、今や本当になくなりました。新しい組み込み関数のmemoryview関数は、（ほとんど）同じような機能を提供します。

* PEP 3119: Abstract Base Classes . 
* PEP 3119: 抽象基底クラス

The abc module and the ABCs defined in the collections module plays a somewhat more prominent role in the language now, and builtin collection types like dict and list conform to the collections.MutableMapping and collections.MutableSequence ABCs, respectively. 

collectionsモジュールによって定義されていたabcモジュールと抽象基底クラス群は、今や言語にとってもっと顕著な役割を果たします。そして、dictやlistのようなコレクション型は、それぞれcollections.MutableMappingやcollections.MutableSequenceの抽象基底クラスに準拠します。

* PEP 3127: Integer Literal Support and Syntax . 
* PEP 3127: 整数リテラルのサポートと構文

As mentioned above, the new octal literal notation is the only one supported, and binary literals have been added.
上述した通り、8進数は新しいリテラル表記だけがサポートされます。そしてバイナリリテラルが追加されています。

* PEP 3129: Class Decorators . 
* PEP 3129: クラスデコレータ(修飾子)

* PEP 3141: A Type Hierarchy for Numbers .
* PEP 3141: 数値の型階層

The numbers module is another new use of ABCs, defining Python’s “numeric tower”. 
numbersモジュールは、Pythonの『numeric tower(数値の塔)』によって定義された、別の新しい抽象基底クラスが使用されます。

Also note the new fractions module which implements numbers.Rational .
また、numbers.Rationalを実装した新しいfractionsモジュール(分数モジュール)にも注意してください。 

Library Changes
ライブラリの変更

Due to time constraints, this document does not exhaustively cover the very extensive changes to the standard library.
時間の制約のため、この文書は標準のライブラリの、あまりにも広範囲な変更を、徹底的にカバーしているわけではありません。

PEP 3108 is the reference for the major changes to the library. 
PEP 3108は、ライブラリの比較的大きな変更の、リファレンスです。

Many old modules were removed.
多くの古いモジュールが削除されました。 

Some, like gopherlib (no longer used) and md5 (replaced by hashlib), were already deprecated by PEP 0004.
（たとえば）いくつかの、(すでに使われていなかった)gopherlibモジュールや、(hashlibに置き換えられた)md5モジュールなどは、すでにPEP 0004において非推奨となっていました。

Others were removed as a result of the removal of support for various platforms such as Irix, BeOS and Mac OS 9 (see PEP 0011).
その他には、IrixやBeOS、そしてMac OS9などの様々なプラットフォームがサポートを打ち切られた結果として削除されたものもあります。

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.
あるモジュール群は、使用されないために、あるいはより良い代替存在するために、Python 3.0で削除されることが選択されました。

* The bsddb3 package was removed because its presence in the core standard library has proved over time to be a particular burden for the core developers due to testing instability and Berkeley DB’s release schedule.
bsddb3パッケージは、コアの標準ライブラリの中のその存在が、テストの不安定と、バークレイDBのリリーススケジュールによるコア開発者のための特定の負担であると、時間とともに判明したので、削除されました。

However, the package is alive and well, externally maintained at http://www.jcea.es/programacion/pybsddb.htm .
しかしながら、そのパッケージはまだ存在しています。そして、立派に外部(http://www.jcea.es/programacion/pybsddb.htm)で維持管理されています

* Some modules were renamed because their old name disobeyed PEP 0008, or for various other reasons.
* あるモジュール群は改称されました。なぜなら古い名前はPEP 0008の規則に反しているから、など様々な理由からです。

旧名称 ⇒ 新名称
_winreg ⇒ winreg
ConfigParser ⇒ configparser
copy_reg ⇒ copyreg
Queue ⇒ queue
SocketServer ⇒ socketserver
markupbase ⇒ _markupbase
repr ⇒ reprlib
test.test_support ⇒ test.support

A common pattern in Python 2.x is to have one version of a module implemented in pure Python, with an optional accelerated version implemented as a C extension; for example, pickle and cPickle . 
Pythonの2.xのモジュールに共通のパターンは、例えばpickleモジュールとcPickleモジュールのように、pure Pythonで実装されたモジュールとともに、オプションとして高速バージョンのCで実装された拡張がある、ということです。

This places the burden of importing the accelerated version and falling back on the pure Python version on each user of these modules.
このパターンは、高速バージョンを導入しpure Python バージョンに頼る、これらのモジュールを使用するユーザにとって負担になります。

In Python 3.0, the accelerated versions are considered implementation details of the pure Python versions.
Python 3.0では、高速バージョンはpure Python バージョンの実装の詳細とみなされます。

Users should always import the standard version, which attempts to import the accelerated version and falls back to the pure Python version.
高速バージョンを導入し、そしてpure Pythonのバージョンに頼りたい時は、ユーザはいつも標準バージョンを導入すべきです。

The pickle / cPickle pair received this treatment.
pickleモジュールとcPickleモジュールのペアは、この処理を受けました。

The profile module is on the list for 3.1.
profileモジュールが、3.1のリストに上がっています。

The StringIO module has been turned into a class in the io module.
StringIOモジュールはioモジュールのクラスになっています。

Some related modules have been grouped into packages, and usually the submodule names have been simplified.
幾つかの関連するモジュール群はパッケージにまとめられています。そして通常サブモジュール名は単純化されています。

The resulting new packages are:
結果として新しいパッケージは……

・dbm (anydbm, dbhash, dbm, dumbdbm, gdbm, whichdb).

・html (HTMLParser, htmlentitydefs).

・http (httplib, BaseHTTPServer, CGIHTTPServer, SimpleHTTPServer, Cookie, cookielib).

・tkinter (all Tkinter-related modules except turtle). 
・tkinter (turtleモジュールを除く全てのTkinter関連のモジュール)

The target audience of turtle doesn’t really care about tkinter. 
turtleモジュールの対象の聴衆は、本当はtkinterを気にしません。

Also note that as of Python 2.6, the functionality of turtle has been greatly enhanced.
また、Python2.6現在、turtleモジュールの機能性が大いに強化されていることに注意してください。

・urllib (urllib, urllib2, urlparse, robotparse).

・xmlrpc (xmlrpclib, DocXMLRPCServer, SimpleXMLRPCServer).

Some other changes to standard library modules, not covered by PEP 3108:
PEP 3108でカバーされない、標準ライブラリモジュールのいくつかの別の変更

* Killed sets .
* setsモジュールを消去します。

Use the builtin set() function.
組み込みのset関数を使用してください。

* Cleanup of the sys module: removed sys.exitfunc() , sys.exc_clear() , sys.exc_type , sys.exc_value , sys.exc_traceback .
* sysモジュールの整理: sys.exitfunc関数、sys.exc_clear関数、sys.exc_type関数、sys.exc_value関数、sys.exc_traceback関数の削除

(Note that sys.last_type etc. remain.)
(sys.last_type等は残っていることに注意してください)

* Cleanup of the array.array type: the read() and write() methods are gone; use fromfile() and tofile() instead.
* array.array型の整理: readメソッドとwriteメソッドはなくなりました。fromfileメソッドとtofileメソッドを代わりに使用して下さい

Also, the 'c' typecode for array is gone - use either 'b' for bytes or 'u' for Unicode characters.
また、arrayの'c'タイプコードはなくなりました。bytesオブジェクトのための'b'を、ユニコード文字のための'u'のいずれかを用いてください。

* Cleanup of the operator module: removed sequenceIncludes() and isCallable() .
* operatorモジュールの整理: sequenceIncludes関数とisCallable関数の削除

* Cleanup of the thread module: acquire_lock() and release_lock() are gone; use acquire() and release() instead.
* threadモジュールの整理: acquire_lock関数とrelease_lock関数がなくなりました。acquire関数とrelease関数を代わりに使用してください。

* Cleanup of the random module: removed the jumpahead() API.
* randomの整理: jumpahead関数とそのAPIが削除されました。

* The new module is gone.
* newモジュールがなくなりました。

* The functions os.tmpnam() , os.tempnam() and os.tmpfile() have been removed in favor of the tempfile module.
* tempfileモジュールのために、os.tmpnam関数、os.tempnam関数、そしてos.tmpfile関数が削除されました。

* The tokenize module has been changed to work with bytes.
* tokenizeモジュールがbytesに対して働くように変更されました。

The main entry point is now tokenize.tokenize() , instead of generate_tokens.
メインのエントリーポイントは、generate_tokensに代わり、今やtokenize.tokenize関数になりました。

* string.letters and its friends ( string.lowercase and string.uppercase ) are gone.
 string.lettersとその仲間(string.lowercaseとstring.uppercase)はなくなりました。

Use string.ascii_letters etc. instead.
代わりにstring.ascii_letters等を使用してください。

(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”.)
(削除の理由は、string.lettersやその仲間が地域依存の動作を持っていたことである。そしてそれは、そのように魅力的に名付けられたグローバル「定数」のための悪いアイデアである)。

* Renamed module __builtin__ to builtins (removing the underscores, adding an ‘s’).
* __builtin__モジュールがbuiltinsに改称されました(アンダースコアが無くなり、's'が追加されました)

The __builtins__ variable found in most global namespaces is unchanged.
殆どのグローバルな名前空間で見出される__builtins__の変数は、変更されていません。

To modify a builtin, you should use builtins , not __builtins__ !
『組み込み』を修正するには、__builtins__ではなくbuiltinsを使用する必要があります！

PEP 3101 : A New Approach To String Formatting
PEP 3101: 文字列書式設定の新しいアプローチ

* A new system for built-in string formatting operations replaces the % string formatting operator.
* 『%』による文字列書式の操作に代わって、新しい組み込み文字列書式の操作のシステムが置き換えられます。

(However, the % operator is still supported; it will be deprecated in Python 3.1 and removed from the language at some later time.) Read PEP 3101 for the full scoop.
(しかしながら、『%』演算子はまだサポートされています。それはPython 3.1に於いて非推奨とされ、さらに後に言語から削除されます）完全な記事は、PEP 3101を読んでください

Changes To Exceptions
例外処理の変更

The APIs for raising and catching exception have been cleaned up and new powerful features added:
例外の発生や受容についてのAPIは整理されました。そして新しく強力な特徴が追加されました：

* PEP 0352 : All exceptions must be derived (directly or indirectly) from BaseException . 
* PEP 0352 : すべての例外オブジェクトがBaseExceptionから（直接または間接的に）を生成される必要があります  。 

This is the root of the exception hierarchy.
BaseExceptionは、例外オブジェクトの階層のルートです。

This is not new as a recommendation, but the requirement to inherit from BaseException is new.
これは勧告として新しくないけれども、「BaseExceptionから継承することが必須である」という『必要条件』としては新しい。

(Python 2.6 still allowed classic classes to be raised, and placed no restriction on what you can catch.) 
(Python 2.6ではまだ旧スタイルのクラスが発生できるようになっています。そして、受容については特に制限されていません)

As a consequence, string exceptions are finally truly and utterly dead.
その結果、文字列による例外は最終的に、真に、そして完全に息の根を止められます。

* Almost all exceptions should actually derive from Exception ; BaseException should only be used as a base class for exceptions that should only be handled at the top level, such as SystemExit or KeyboardInterrupt .
ほぼすべての例外は、実質的にはExceptionから派生しなければなりません。 BaseExceptionが基底クラスとして使われなければならない『例外』は、SystemExitやKeyboadInterruptなどのようにトップレベルを操作しなければならないものに限られます。

The recommended idiom for handling all exceptions except for this latter category is to use except Exception .
この後者のカテゴリーを除き、すべての例外を処理するための『例外』のイディオムとしては、Exceptionを使用することです。

* StandardError was removed (in 2.6 already).
* StandardErrorは削除されました(2.6に於いて既に)

* Exceptions no longer behave as sequences.
* Exceptionsは、もはやシーケンスとして動作していません。

Use the args attribute instead.
そのかわりにargs属性を使用してください。

* PEP 3109 : Raising exceptions. 
* PEP 3109 : 例外を発生させる

You must now use raise Exception ( args ) instead of raise Exception, args. Additionally, you can no longer explicitly specify a traceback; instead, if you have to do this, you can assign directly to the __traceback__ attribute (see below).

今や、『raise Exception(args)』を『raise Exception, args』の代わりに使わなければなりません。さらに、もう明示的にトレースバックを指定することはできません。代わりに、もしこれを行うには、直接__traceback__属性に割り当てることができます
（下記参照） 。

* PEP 3110 : Catching exceptions.
* PEP 3110 : 例外の受容

You must now use except SomeException as variable instead of except SomeException , variable .
今や『except SomeException as variable』を『except SomeException , variable』の代わりに使用しなければなりません。

Moreover, the variable is explicitly deleted when the except block is left.
また、variableはexcept節が終わった時、確実に消去されます

* PEP 3134 : Exception chaining.
* PEP 3134 : 例外の連鎖

There are two cases: implicit chaining and explicit chaining.
暗黙の連鎖と明示的な連鎖の２例があります。

Implicit chaining happens when an exception is raised in an except or finally handler block.
暗黙の連鎖は、例外を処理するexcept節やfinally節の中で例外が発生するときに起きます。

This usually happens due to a bug in the handler block; we call this a secondary exception.
これは通常、処理節の中のバグによって発生します。我々はコレを『二次例外』と呼んでいます。

In this case, the original exception (that was being handled) is saved as the __context__ attribute of the secondary exception. 
この場合、元の例外（制御されている）が二次例外の__context__属性として保存されています。

Explicit chaining is invoked with this syntax:
明示的な連鎖この構文で引き起こされます：

	raise SecondaryException() from primary_exception

(where primary_exception is any expression that produces an exception object, probably an exception that was previously caught).
(primary_exceptionはexceptionオブジェクトから生成されたどんな例外でも、多分、それは以前に受容されたものでしょう）

In this case, the primary exception is stored on the __cause__ attribute of the secondary exception.
この場合、主な例外は、二次例外の__cause__属性に格納されています。 

The traceback printed when an unhandled exception occurs walks the chain of __cause__ and __context__ attributes and prints a separate traceback for each component of the chain, with the primary exception at the top.
未処理の例外が発生するとき連鎖の__cause__属性 and __context__属性が働き、分離してトレースバックそれぞれの連鎖のコンポーネント毎に出力します。先頭で主な例外がともに、トレースバックとして出力されます

 (Java users may recognize this behavior.)
（ Javaのユーザーは、この現象を認識することがあります。 ）

* PEP 3134: Exception objects now store their traceback as the __traceback__ attribute. 
* PEP 3134: 例外オブジェクトのは今や__traceback__属性としてのトレースバックを保存します。

This means that an exception object now contains all the information pertaining to an exception, and there are fewer reasons to use sys.exc_info() (though the latter is not removed).

これは、例外オブジェクトに今や例外に係るすべての情報が含まれていることを意味します。そしてsys.exc_info関数を使う理由が薄くなったことも（ただし、後者は別に削除されません）

* A few exception messages are improved when Windows fails to load an extension module.
* いくつかの例外のメッセージは、Windowsが拡張モジュールをロードするのに失敗したときのために改善されています。

For example, error code 193 is now %1 is not a valid Win32 application .
For example, error code 193 is now %1 is not a valid Win32 application .
たとえば、 エラーコード193は今や『%1 は有効なWin32アプリケーションではありません』になっています。

（訳注：多分％１とは、バッチファイルで言うプログラム実行時の第一引数のことと思われる）

Strings now deal with non-English locales.
文字列は今や英語以外のロケールに対応します。

Miscellaneous Other Changes
雑多なその他の変更

Operators And Special Methods
演算子や特殊メソッド

* != now returns the opposite of == , unless == returns NotImplemented .
* 『!=』は、『==』がNotImplementedを返さない限り、『==』の反対を返します。

* The concept of “unbound methods” has been removed from the language.
* 『unbound methods(非連結のメソッド)』というコンセプトは言語から削除されました。

When referencing a method as a class attribute, you now get a plain function object.
クラス属性としてメソッドを参照するときは、ただの関数オブジェクトとなります。

（訳注：
>>> class X:
...   def ooo(self, other):
...     print(self,other)
...
>>> X.ooo(1,2)
1 2
>>>
　……というようなことが出来るようになった、という意味。以前はX.oooはunbound methodsとして、第一引数はXのインスタンス以外は受け付けなかった。この変更の効用としては、クラスを、単なる関数をまとめる入れ物として使いやすくした、と考えられる）

* __getslice__() , __setslice__() and __delslice__() were killed.
* __getslice__メソッドと__setslice__メソッド、そして__delslice__は抹消された。

The syntax a[i:j] now translates to a.__getitem__(slice(i, j)) (or __setitem__() or __delitem__() , when used as an assignment or deletion target, respectively).
『a[i:j]』構文は今やa.__getitem__(slice(i, j))に変換されます(代入や削除の操作をするなら__setitem__メソッドか__delitem__に置き換えられます）

* PEP 3114: the standard next() method has been renamed to __next__() . 
* PEP 3114: next標準メソッドは、__next__メソッドに改称されました。

（訳注：そのかわりにイテレータオブジェクトの順送りには、next標準関数が使える）

* The __oct__() and __hex__() special methods are removed - oct() and hex() use __index__() now to convert the argument to an integer.
* 特殊メソッド__oct__と__hex__が削除されました。oct関数とhex関数は、整数引数を変換するために今や__index__メソッドを使用します。

* Removed support for __members__ and __methods__ .
* __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.
func_Xと名づけられていた関数の属性は、__X__というフォームに改称されました。古いfunc_X形式の名前は関数の属性の名前空間は、ユーザが定義する属性(名)として解放されました。

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.

即ちfunc_closure、func_code、func_defaults、func_dict、func_doc、func_globals、func_nameはそれぞれ__closure__、__code__、__defaults__、__dict__、__doc__、__globals__、__name__に改称されました。

* __nonzero__() is now __bool__() .
* __nonzero__メソッドは、現在__bool__メソッドです。

Builtins
組み込み(関数,オブジェクト,型など)

* PEP 3135 : New super() .
* PEP 3135 : 新super関数

You can now invoke super() without arguments and (assuming this is in a regular instance method defined inside a class statement) the right class and instance will automatically be chosen.
super関数を引数無しで呼び出すと、正しいクラスとインスタンスが自動的に選択されます（これは、クラス文の中で定義された普通のインスタンスメソッドを想定しています）

With arguments, the behavior of super() is unchanged.
引数つきでは、super関数の動作は別に変更されていません。

* PEP 3111 : raw_input() was renamed to input() .
* PEP 3111 : raw_input関数がinput関数に改称されました。

That is, the new input() function reads a line from sys.stdin and returns it with the trailing newline stripped. 
つまり、新しいinput関数はsys.stdinから１行を読み取り、末尾の改行を除去してそれを返します。

It raises EOFError if the input is terminated prematurely. 
入力が完了せずに打ち切られると、EOFErrorが発生します。

To get the old behavior of input() , use eval(input()) .
古いinput関数の動作（の結果）を取得するには『eval(input())』を使用してください。

* A new builtin next() was added to call the __next__() method on an object.
* 新しい組み込み関数のnextは、オブジェクトの__next__メソッドを呼び出すために追加されました。

* Moved intern() to sys.intern() .
* intern関数はsys.intern関数へ移動しました。

* Removed: apply().
* apply関数は削除されました。

Instead of apply(f, args) use f(*args)
『apply(f, args)』の代わりに、『f(*args)』を使用してください。

* Removed callable().
* callable関数は削除されました。

Instead of callable(f) you can use hasattr(f, '__call__') .
『callable(f)』の代わりに、『hasattr(f, '__call__')』が使えます。

The operator.isCallable() function is also gone.
operator.isCallable関数もなくなりました。

* Removed coerce() .
* coerce関数は削除されました。

This function no longer serves a purpose now that classic classes are gone.
この関数は、もはや旧スタイルのクラスが無くなった今、なんの用途も提供しません。

* Removed execfile() .
* execfile関数は削除されました。

Instead of execfile(fn) use exec(open(fn).read()) .
『execfile(fn)』の代わりに『exec(open(fn).read())』を使用します。

* Removed file .
* file関数が削除されました。

Use open().
open関数を使用してください。

* Removed reduce() .
* reduce関数が削除されました。

Use functools.reduce() if you really need it;
もし本当に必要なら、functools.reduce関数を使ってください

however, 99 percent of the time an explicit for loop is more readable.
とはいえ、99パーセントの場合、明示的な『for ループ』のほうが読みやすくなります。

* Removed reload() .
* reload関数は削除されました。

Use imp.reload() .
imp.reload関数を使用してください。

* Removed. dict.has_key() - use the in operator instead.
* dict.has_keyメソッドは削除されました。in 演算子を使用してください。

Build and C API Changes
ビルドとＣ言語へのAPIの変更

Due to time constraints, here is a very incomplete list of changes to the C API.
時間の制約があるため、これでは、 C言語へのAPIの変更の、非常に不完全なリストです。

* Support for several platforms was dropped, including but not limited to Mac OS 9, BeOS, RISCOS, Irix, and Tru64.
* Mac OS 9やBeOSやRISCOSやIrix、そしてTru64を含め、そしてそれに限らず、いくつかのプラットフォームのサポートの提供が打ち切られました。

* PEP 3118 : New Buffer API.
* PEP 3118 : 新しいBuffer API.

* PEP 3121: Extension Module Initialization & Finalization.
* PEP 3121: 拡張モジュールの初期化と終了作法。

* PEP 3123 : Making PyObject_HEAD conform to standard C.
* PEP 3123 : PyObject_HEADが標準Ｃに準拠されました。

* No more C API support for restricted execution.
* 実行を制御するためのC APIは、もうサポートされていません。

* PyNumber_Coerce , PyNumber_CoerceEx , PyMember_Get , and PyMember_Set C APIs are removed.
* ＣのAPIのPyNumber_Coerce、PyNumber_CoerceEx、PyMember_Get、とPyMember_Setは、削除されました。

* New C API PyImport_ImportModuleNoBlock , works like PyImport_ImportModule but won’t block on the import lock (returning an error instead).
* 新しいＣのAPIのPyImport_ImportModuleNoBlockは、PyImport_ImportModuleのように働きます。しかし、import lockをブロックしません（エラーを返す代わりに）

* Renamed the boolean conversion C-level slot and method: nb_nonzero is now nb_bool .
* Cレベルのスロットとメソッドのブール変換の改称：nb_nonzeroは今やnb_boolです。

* Removed METH_OLDARGS and WITH_CYCLE_GC from the C API.
* METH_OLDARGSとWITH_CYCLE_GCがCのAPIから削除されました。

Performance
パフォーマンス

The net result of the 3.0 generalizations is that Python 3.0 runs the pystone benchmark around 10% slower than Python 2.5.
3.0の一般化の正味の結果は、pystoneベンチマークでPython3.0がPython2.5より約10%遅く走るということです。

Most likely the biggest cause is the removal of special-casing for small integers. 
おそらく、最も大きな原因は小さな整数のための特殊なケーシングの除去にあるのでしょう。

There's room for improvement, but it will happen after 3.0 is released!
実装に改善の余地があるけれども、3.0がリリースされた後に、それは起こるでしょう！

Porting To Python 3.0
Python 3.0への移植

For porting existing Python 2.5 or 2.6 source code to Python 3.0, the best strategy is the following:
既存のPython 2.5または2.6のソースコードをPython 3.0に移植するための最適な戦略は以下の通りです：

0. (Prerequisite:) Start with excellent test coverage.
0. (前提条件)優れたテスト適用から開始します。

1. Port to Python 2.6.
1. Python 2.6から移行。

This should be no more work than the average port from Python 2.x to Python 2.(x+1).
これはPython 2.x から Python 2.(x+1)への平均的な移行以上の仕事はしません。

Make sure all your tests pass.
すべてのテストに合格していることを確認。

2. (Still using 2.6:) Turn on the -3 command line switch.
2. (それでも2.6を使用して:)-3コマンドラインスイッチを（ひねって）ONにします。

This enables warnings about features that will be removed (or change) in 3.0.
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.

再度テストスイートを走らせます。そして何の警告も上がらなくなるまで、全てのテストがパスするまで、警告に従ってコードを修正します。

3. Run the 2to3 source-to-source translator over your source code tree.
3. 2to3ソースコード間トランスレータをソースコードツリーに対して走らせます。

(See 2to3 - Automated Python 2 to 3 code translation for more on this tool.) 
(2to3を参照のこと - このツールで自動的にPython2から3のコード変換以上のことをしてくれます) 

Run the result of the translation under Python 3.0. 
変換結果をPython 3.0下で走らせます。

Manually fix up any remaining issues, fixing problems until all tests pass again. 
手動で、すべてのテストに再び通過するまで問題を解決して、いかなる残った問題でも修正してください。

It is not recommended to try to write source code that runs unchanged under both Python 2.6 and 3.0; you’d have to use a very contorted coding style, eg avoiding print statements, metaclasses, and much more.

Python2.6と3.0両方の下で不変になるソースコードを書き込もうとすることは、お勧めできません；あなたは、まさしくその曲げられたコーディングスタイル、たとえば、print文やメタクラスやあるいはもっと多くの多くのものを避けることを強要されるでしょうから。

If you are maintaining a library that needs to support both Python 2.6 and Python 3.0, the best approach is to modify step 3 above by editing the 2.6 version of the source code and running the 2to3 translator again, rather than editing the 3.0 version of the source code.
あなたが、Python 2.6とPython 3.0の両方をサポートする必要があるライブラリをメンテナンスしているならば、最もよいアプローチは、3.0バージョンのソースコードを編集するよりも、修正ステップ3に従って2.6バージョンのソースコードを編集し、再び2to3トランスレータを実行することでしょう。

For porting C extensions to Python 3.0, please see Porting Extension Modules to 3.0
C拡張のPython3.0への移植のためには、どうぞ『Porting Extension Modules to 3.0』をご覧下さい。