TSpython 発言

Bruce.です。

なんやかんやで一日過ぎてしまいました。
できるだけ cosmetic なところはスルーして、大きめ(と思われる)なところに
絞りました。

機械伯爵 さんは書きました (2009/01/15 7:54):
> 　ということで、後半、ようやくアップできます。
> 
> ※昨日学校が無かったので、一日がかりでした。
> 
> 　チェック終わりしだい、全文をWikiにアップします
> ので、そこでの修正もあればお願いいたします。
> 
> ＜つづき＞


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

既に2.6では使えます
→
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関数に対応します。

既に2.6では使えます
→
2.6でも既に使えます
2.6では使えます

* 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では部分的に実施されています）
→
2.6では部分的にNoneに関する制限の強制を行っています。

* 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__変数は、もはやサポートされていません。


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.

また、リスト内包表現は別の意味を持つことに気をつけてください。これらはリストのコンスト
ラクタとしてジェネレータ式を用いることを終わらせる構文糖衣です。そして、個々のループを
制御する変数は、もはや周囲のスコープに漏れません。

→
(list comprehensions は)
list()コンストラクター の内部で式を生成するための syntactic sugar (訳語はお好きに)
のようなものです。特に、(list comprehensions にある)ループの制御変数は
ループを囲むスコープに漏れないようになりました。


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


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

→
atomic expression => アトム表現てのは?
たぶん分解することのできない字句要素ということではないかと
( '...' で一つの字句要素)。

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

atomic expression はこれまでスライスの中でのみ許されていた。
そして ... と記述しなければならない。

(Previously it could also be spelled as . . . , by a mere accident of the grammar.)
（以前にも、スペルかもしれない。 。 。 。 。 は 、文法のは単なる偶然。 ）
以前は a mere accident of the grammar によって
. . . (間に空白が入っている) という記述も許されていた。


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

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

あってます。→ backticks == ``

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

→
acceptted の訳?



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に逆移植されたように感じ
るでしょう。

→
reminds the reader の reader が訳文から抜け落ちているので、
全体として文がおかしな印象が。末尾の「感じるでしょう」の主語は?

おそらく多くのユーザーはPython 2.5 から Python 3.0 へ直接移行するでしょうから、
このセクションは
新しい機能は元々 Python 3.0のために設計されたもので
Python 2.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する必要はありません。

→
__future__ から import することなく通常の機能として with 文が使えるようになりました。
とか。


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から非使用を訴えることを始めます。

→
この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する必要はありません。

→
このやり方(方式は)標準のものとなったので、__future__ を　import する必要はなくなりました。


* 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のインスタンスです。

→
ioモジュールはファイル入出力を行うための新しい標準的な方法となりました。
これとあわせて sys.stdin , sys.stdout and sys.stderr
の初期値は 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』と
してアクセスできます（ただし、エンコーディング操作やデコーディング操作のスピードアップ
のために、テキストオブジェクトが、そのもののバッファを維持するよう気をつけてください）

→
テキストオブジェクトが
エンコードやデコードの操作を高速化するために
自身のバッファを maintains していることに注意してください。


* 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の抽象基底クラスに準拠しま
す。

→
abc モジュールと、collections モジュールで定義されていた抽象基底クラス群 (ABC)は〜



* 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(数値の塔)』によって定義された、別の新しい抽象基底クラスが使用されます。

→
Numerical tower - Wikipedia, the free encyclopedia
http://en.wikipedia.org/wiki/Numerical_tower

In Scheme and some other Lisp dialects, a numerical tower is the set of data types
that represent numbers in a given programming language.

Each type in the tower conceptually "sits on" a more fundamental type, so an integer
is a rational number and a number, but the inverse is not necessarily true, i.e. not
every number is an integer; this asymmetry implies that a language can allow implicit
coercions of numerical types - without creating semantic problems - in only one
direction: coercing an integer to a rational loses no information and does not affect
the results of a function, but to coerce most reals to an integer could well result in
a problem (for example, the real 1/3 does not equal any integer).

Scheme programming language, and also other Lisp dialects, defines all its arithmetic
within this model[1]. Some given implementations may extend or adapt the tower. Kawa
Scheme, for example, extends it with a Quantity type that is even more generic than
Number. Smalltalk is another programming language that follows this model, but it has
a Magnitude as superclass of Number. Another popular variant is having both exact and
inexact versions of the tower or parts of it. Most languages and language
implementations do not support a Scheme-like numerical tower. Some languages support
it only in a limited way.


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を読んでください
→
% 演算子はまだサポートされてはいますが、
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から（直接または間接的に）を生成される必要があります  。
→
すべての例外は 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などのよ
うにトップレベルを操作しなければならないものに限られます。
→
should なので、〜しなければなりません はちと強すぎ?

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 : 例外の受容

→
Catch → 捕捉?
他の言語は多分捕捉で一貫している。

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__属性として保存されています。

→
that was being handled
その時点で処理の真っ最中である orignal exception 〜

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オブジェクトから生成されたどんな例外でも、多分、それは以
前に受容されたものでしょう）

一貫して accept → 受容と訳されていますが(統一されてること自体はいいですが)、
CSの分野では accept に受容という訳語を当てるのはほとんどないような気がします。
ということで違和感あり。
もちろん機械さんなりの判断基準でもって、受容でよいのだという判断をされたのなら
それはそれでよいと思います。

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__属性が働き、分離してトレ
ースバックそれぞれの連鎖のコンポーネント毎に出力します。先頭で主な例外がともに、トレー
スバックとして出力されます

→
なんとも訳しにくい文ですが
primary exceptionが「主な例外」というのはちと違うのではないかと。

unhandled exception が chain of __cause__ and __context__ attributes
を walk　し、(渡り歩いている　each componet of the chain で)
separate traceback を出力したときに、t
he primary exception を at the top に伴って
tracebackが print されます
ということで、
どうまとめましょうか(^^;

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

この recoginizeも文全体とその説明している状況を考えると「認識」
というのは違和感があります。

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

→
例外オブジェクトは __traceback__ 属性として store されるようになりました。
ぐらい?
これまた一貫して now が出てくる文で「今や〜」というパターンになっていますが
あまりにたくさんで過ぎていてうざったい感じがあります。

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関数を使う理由が薄くなったことも（ただし、後者は別に削除されません）

これは例外オブジェクトに(その)例外に関する情報のすべてが含まれるようになったということです。
それにより、sys_exc_info() を使う理由は少なくなりました
(とはいえ削除されてはいません)。

ぐらい?

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

→
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を返さない限り、『==』の反対を返します。

→
ここでは now が無視されてます?

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

→
unbound は bind の活用形の否定であり、「束縛されていない」というような
訳になると思います。


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

→
now。

（訳注：
>>> 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__メソッドを使用します。

→
今や(ry


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

→
now

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関数を引数無しで呼び出すと、正しいクラスとインスタンスが自動的に選択されます（こ
れは、クラス文の中で定義された普通のインスタンスメソッドを想定しています）

→
now

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

→
引数つきの super()の動作には変更ありません。



* 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です。

→
今や(ry

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から移行。

→
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)への平均的な移行以上の仕事はしません。

このステップ(2.6への以降)の作業は、
これまでの 2.2→2.3 とか 2.4→2.5のような以降のときと比べても
目立って多くなることはないというような意味ですよね?

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

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

→
このステップでも「まだ」2,6を使用しています。
で、-3 をONにすると。

This enables warnings about features that will be removed (or change) in 3.0.
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ソースコード間トランスレータをソースコードツリーに対して走らせます。

source-to-source translator がソースコード間トランスレータというのは?


(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.
手動で、すべてのテストに再び通過するまで問題を解決して、いかなる残った問題でも修正してください。

→
再びすべてのテストを通過するまで手作業で残っている issue を修正して
問題を解決してください。
とか。

-- 
木村浩一
  I thought what I'd do was, I'd pretend I was one of those deaf-mutes or should I?
  mail kbk [at] kt.rim.or.jp
        web  www.kt.rim.or.jp/~kbk/zakkicho/
             homepage3.nifty.com/farstar/