TSpython 発言

　機械です。

　全文アップは時間がかかりそうなので、とりあえず出来ているところまでアップします。

　訳文がヘンなところは、ご指摘お願いいたします。

What’s New In Python 3.0
Author:	Guido van Rossum
Release:	3.0
Date:	January 04, 2009

Python 3.0 の新機能
著者：Guido van Rossum
日付：2009年1月4日

This article explains the new features in Python 3.0, compared to 2.6. Python 3.0, also known as “Python 3000” or “Py3K”, is the first ever intentionally backwards incompatible Python release.
　この記事は、Python 2.6と比較したPython 3.0の新機能について説明します。"Python 3000"および"Py3k"として知られているPython 3.0は、下位互換を意図的に除いたPythonの始めてのリリースです。

There are more changes than in a typical release, and more that are important for all Python users.
ここには全てのPythonユーザにとって重要な、より多くの変更があります。
 
Nevertheless, after digesting the changes, you’ll find that Python really hasn’t changed all that much ? by and large, we’re mostly fixing well-known annoyances and warts, and removing a lot of old cruft.
にもかかわらず、変更を理解した後に、あなたは、Pythonが本当は概してすべてのその多くを変更しなかったと気付くでしょう。そして私達は、たいてい有名な困り事と醜いものを修正していて、たくさんの古い嫌なものを削除しています。

This article doesn’t attempt to provide a complete specification of all new features, but instead tries to give a convenient overview. For full details, you should refer to the documentation for Python 3.0, and/or the many PEPs referenced in the text.
この記事では、すべての新機能の完全な仕様を説明するつもりはありませんが、代わりに便利な概観を提示します。詳細については、あなたはPython 3.0のドキュメント、あるいはそこで参照されている多くのPEPを参照してください

If you want to understand the complete implementation and design rationale for a particular feature, PEPs usually have more details than the regular documentation; but note that PEPs usually are not kept up-to-date once a feature has been fully implemented.
あなたが、完全な実装と特定の機能のための設計原理を理解したいならば、PEPsは通常のドキュメントより多くの詳細な情報を持っています。ただし機能が完全に実装されたら、PEPsが普通アップデートしないことに注意してください。

Due to time constraints this document is not as complete as it should have been.
時間的制約のため、この文書は（かくあるべきとされるほど）完全ではありません。

As always for a new release, the Misc/NEWS file in the source distribution contains a wealth of detailed information about every small thing that was changed.
いつものように新しいリリースでは、ソースの配布物の中の『その他/ニュース』のファイルに、変更されたすべての小さなものに関する詳細な情報が満載されています。

Common Stumbling Blocks
共通の障害

This section lists those few changes that are most likely to trip you up if you’re used to Python 2.5.
このセクションでは、Python 2.5を使用しているほとんどの人がつまづく幾つかの変更点がリストアップされています。

Print Is A Function
『print』は関数に

The print statement has been replaced with a print() function, with keyword arguments to replace most of the special syntax of the old print statement
古いprint文の特殊な文法は廃止され、print関数（とキーワード引数）に置き換えられました。

Examples:
例

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

Old : print x , # Trailing comma suppresses newline
New : print ( x , end = " " ) # Appends a space instead of a newline
旧：print x , # 末尾のコンマの改行を抑制
新：print ( x , end = " " ) # スペースの代わりに改行を付加 

Old : print # Prints a newline
New : print () # You must call the function!
旧：print # 改行を出力
新：print() # 『print関数』を呼び出す必要があります印刷

Old : print >> sys . stderr , "fatal error"
New : print ( "fatal error" , file = sys . stderr )
旧：print >> sys.stderr , "fatal error"
新：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(x , y) # repr((x, y))を出力
新：print (( x , y )) # print(x, y)とは別！

You can also customize the separator between items, e.g.:
print("There are <", 2**32, "> possibilities!", sep="")
which produces:
There are <4294967296> possibilities!
アイテムとの間のセパレータをカスタマイズすることもできます
例えば……
	print("There are <", 2 ** 32, "> possibilities!", sep = "")
は、
	There are <4294967296> possibilities!
を生成します。


Note:
注記：

* The print() function doesn’t support the “softspace” feature of the old print statement. 
print関数は、昔のprint文の特徴だったsoftspaceをサポートしていません。 

For example, in Python 2.x, print "A\n", "B" would write "A\nB\n" ; but in Python 3.0, print("A\n", "B") writes "A\n B\n" .
例えばPython 2.xでは、
	print "A\n", "B"
は
	"A\nB\n"
を出力しましたが、Python 3.0では
	print("A\n", "B")
は
	"A\n B\n"
を出力します。

* Initially, you’ll be finding yourself typing the old print x a lot in interactive mode. Time to retrain your fingers to type print(x) instead!
最初あなたは、インタラクティブモードで何度も『print x』と打ってしまう（ことに気づく）でしょう。（しかし）時間が、あなたの指を（かわりに）『print(x)』（と打てるよう）に再教育するでしょう。

* When using the 2to3 source-to-source conversion tool, all print statements are automatically converted to print() function calls, so this is mostly a non-issue for larger projects.
(2.x→3.0)のソース変換ツールである"2to3"を使うと、全print文が自動的にprint関数呼び出しに変換されます。よってこれは大部分の大きなプロジェクトにとって問題ではありません。

Views And Iterators Instead Of Lists
リスト(list)の代りにビュー(view)と反復子(iterator)を

Some well-known APIs no longer return lists:
いくつかのよく知られているAPIは、もはやリストを返しません。

* dict methods dict.keys() , dict.items() and dict.values() return “views” instead of lists.
辞書(dict)のメソッドのdict.keys, dict.items, dict.valuesは、リストの代りにビュー(view)を返します。

For example, this no longer works: k = d.keys();k.sort() .
例えば、こういった使い方は既にできません。
	k = d.keys()
	k.sort()

Use k = sorted(d) instead (this works in Python 2.5 too and is just as efficient).
代わりに、sorted(d)を使用します（これはPython 2.5以降でも動きます。

* Also, the dict.iterkeys() , dict.iteritems() and dict.itervalues() methods are no longer supported.
また、dict.iterkeysとdict.iteritemsとdict.itervaluesメソッドは、もはやサポートされていません。

* map() and filter() return iterators. 
map関数とfilter関数は、反復子(iterator)を返します。

If you really need a list, a quick fix is eg list(map(...)) , but a better fix is often to use a list comprehension (especially when the original code uses lambda ), or rewriting the code so it doesn’t need a list at all.
もしあなたが本当にリストが必要なら、一番手っ取り早い方法はlist(map(...))などと修正することですが、一般的により良い修正は、しばしばリストの内包記法を用いることです（特に元のコードでlambdaが使用されているのなら）。そのようにコードを書き直せば、リスト（list関数?）は全く必要ありません。

Particularly tricky is map() invoked for the side effects of the function; the correct transformation is to use a regular for loop (since creating a list would just be wasteful).
特に変則的なmap関数（の濫用）は、関数に副作用を招きます。正しい変換は、普通のループを使用することです（どうせリストを作成するだけ無駄でしょうから）

* range() now behaves like xrange() used to behave, except it works with values of arbitrary size. 
range関数は、任意のサイズの値で動作する以外は、今やxrange関数のように振舞います。

The latter no longer exists.
後者は、もはや存在していません。

* zip() now returns an iterator. 
zip関数は反復子を返します。

Ordering Comparisons
順序の比較

Python 3.0 has simplified the rules for ordering comparisons:
Python 3.0では順序の比較のルールを簡略化しています。

* The ordering comparison operators ( < , <= , >= , > ) raise a TypeError exception when the operands don’t have a meaningful natural ordering.
順序比較演算子(<, <=, >=, >)は、比較するものに意味のある自然な順序が無い時、『TypeError例外』を発生させます。

Thus, expressions like 1 < '' , 0 > None or len <= len are no longer valid, and eg None < None raises TypeError instead of returning False .
したがって、『1 < ''』『0 > None』あるいは『len <= len』といった（比較は）もはや妥当ではありません。たとえば『None > None』の場合、『False(否)』を返すのではなく『TypeError例外』を発生させます。

A corollary is that sorting a heterogeneous list no longer makes sense ? all the elements must be comparable to each other.
結果、異種オブジェクト間のソーティングはもはや意味はありません。全ての要素が互いに比較可能である必要があります。

Note that this does not apply to the == and != operators: objects of different incomparable types always compare unequal to each other.
注意：これらの新しいルールは、（同一性テストにも用いる）『==』や『!=』には適用されません。比較できない異なる型のオブジェクトは、常に互いに『同一ではない』と判定されます。

* builtin.sorted() and list.sort() no longer accept the cmp argument providing a comparison function.
sorted組み込み関数とlist.sortメソッドは、もはや『比較関数』を引数に取ることはできません。

Use the key argument instead.
代わりに『key』という名称のキーワード引数に（比較関数を）渡します。

NB the key and reverse arguments are now “keyword-only”.
注意：キーと逆ソート引数は、今や『キーワード引数のみ』です。

（訳注：sorted(list, reverse=True)とすると、逆順にソートできます(reverse=1でも可)）

* The cmp() function should be treated as gone, and the __cmp__() special method is no longer supported.
cmp関数は動作できるように扱う必要があり、__cmp__特殊メソッドはもはやサポートされません。

Use __lt__() for sorting, __eq__() with __hash__() , and other rich comparisons as needed. (If you really need the cmp() functionality, you could use the expression (a > b) - (a < b) as the equivalent for cmp(a, b) .)
ソーティング（整列）には__lt__メソッド、__eq__メソッド、__hash__メソッド、および必要に応じてその他の豊富な比較方法が用いられます（もし本当にcmp()が関数として必要なら、"(a > b)-(a < b)"をcmp(a, b)と等価のものとして用いることができます）

Integers
整数

* PEP 0237 : Essentially, long renamed to int . That is, there is only one built-in integral type, named int ; but it behaves mostly like the old long type. 
* PEP 0237: 基本的にlongがintへ改称されました。それは、『int』という名の唯一の組み込み整数型です。しかし、殆どの『long』型と同様に動作します。

* PEP 0238 : An expression like 1/2 returns a float. 
* PEP 0238 : 『1 / 2』のような式は、浮動小数点数(float)を返します。

Use 1//2 to get the truncating behavior.
切捨ての（動作を行った）結果を得るには、『1 // 2』を使用します。

(The latter syntax has existed for years, at least since Python 2.2.) 
（後者の構文は、 Python 2.2以降の年から存在しています）

* The sys.maxint constant was removed, since there is no longer a limit to the value of integers. 
sys.maxint定数は削除され、もはや整数値に上限はありません。

However, sys.maxsize can be used as an integer larger than any practical list or string index.
しかしながらsys.maxsize定数は、現実的なリストや文字列の（最大）インデックスよりも大きい数値です。

It conforms to the implementation’s “natural” integer size and is typically the same as sys.maxint in previous releases on the same platform (assuming the same build options).
これは、実装の『自然な』整数のサイズに適合する。そしてこれは、一般的に以前のリリースの同じプラットフォームのsys.maxintと同じである（なお、同一オプションでビルドされたものとする）

* The repr() of a long integer doesn’t include the trailing L anymore, so code that unconditionally strips that character will chop off the last digit instead.
『長整数』のreprでは、後ろに'L'をつけません。従って、無条件に、そのキャラクタを取り除くコードは代わりに最終桁を切り落としてしまうでしょう。

（訳注：reprはrepr関数での出力を意味するとともに、オブジェクトの文字表現を意味する。repr = representation)

* Octal literals are no longer of the form 0720 ; use 0o720 instead. 
八進法のリテラルは、『0720』ではなく『0o720』と書きます。

Text Vs. Data Instead Of Unicode Vs. 8-bit
『Unicode 対 8ビット』の代わりに『テキスト 対 データ』を

Everything you thought you knew about binary data and Unicode has changed.
バイナリデータとUnicodeについて、あなたが知っている全てのことは変わってしまいました。

* Python 3.0 uses the concepts of text and (binary) data instead of Unicode strings and 8-bit strings.
Python 3.0では、『テキストと（バイナリ）データ』の概念を、『Unicode文字列と8ビット』の代わりに採用しています。

All text is Unicode; however encoded Unicode is represented as binary data.
すべてのテキストはUnicodeです。しかしながら、Unicodeのエンコードされたバイナリデータとして表現されています。 

（訳注：UTF-8のこと）

The type used to hold text is str , the type used to hold data is bytes .
テキストを保持するために使用するのは『str』型です。そしてデータを保持するために使用するのは『bytes』型です。

The biggest difference with the 2.x situation is that any attempt to mix text and data in Python 3.0 raises TypeError , whereas if you were to mix Unicode and 8-bit strings in Python 2.x, it would work if the 8-bit string happened to contain only 7-bit (ASCII) bytes, but you would get UnicodeDecodeError if it contained non-ASCII values.
2.ｘの場合との最大の違いは、テキストとデータの如何なる混同の試みでも、Python 3.0ではTypeErrorを発生させるということでしょう。Python 2.xでは、Unicodeと8bitの文字列を混合したとき、(Unicode文字列が)偶然７ビット(ASCII)bytsだけのバイト列であったならば、それは動作したでしょう。しかし、(Unicode文字列が)非ASCII値を含んでいたならば、UnicodeDecodeErrorを見ることになったでしょう。

This value-specific behavior has caused numerous sad faces over the years.
この値固有の現象は、年間で数多くの悲劇に直面しています。

* As a consequence of this change in philosophy, pretty much all code that uses Unicode, encodings or binary data most likely has to change.
この哲学的な変更の結果、ほぼ全てのUnicode、エンコーディング、またはバイナリデータを扱うコードが変更されなければならないでしょう。

The change is for the better, as in the 2.x world there were numerous bugs having to do with mixing encoded and unencoded text.
この変更のほうがマシなのは、2.xの世界では、混同やテキストのエンコード、デコードに関するおびただしいバグがあるからです。

To be prepared in Python 2.x, start using unicode for all unencoded text, and str for binary or encoded data only.
Python 2.xで用意すべきことは、エンコードされていない全てのテキストでUnicodeを使い始めることと、『str』はバイナリデータか、エンコードされたデータのみで使うことでしょう。

Then the 2to3 tool will do most of the work for you.
次に、 2to3ツールがあなたのために作業をほとんどやってくれます。

* You can no longer use u"..." literals for Unicode text. However, you must use b"..." literals for binary data.
あなたはもはや、 Unicodeテキストでu"..."リテラルを使用することはできません。しかしながら、バイナリデータにはb"..."リテラルを使わなければなりません。

* As the str and bytes types cannot be mixed, you must always explicitly convert between them.
str型とbytes型が混同不可能なため、いつでも明示的に相互に変換する必要があります。 

Use str.encode() to go from str to bytes , and bytes.decode() to go from bytes to str .
str.encodeメソッドを使えば、str型からbytes型に変換します。そしてbytes.decodeメソッドは、bytes型からstr型に変換します。

You can also use bytes(s, encoding=...) and str(b, encoding=...) , respectively.
また、それぞれ
	bytes(s, encoding=...)
や
	str(b, encoding=...)
を使うこともできます。

* Like str , the bytes type is immutable. 
str型と同様に、bytes型も不変型です。

There is a separate mutable type to hold buffered binary data, bytearray .
分割した可変型のバイナリデータバッファを保持するためには、bytearray型があります。

Nearly all APIs that accept bytes also accept bytearray .
bytes型オブジェクトを受け入れるAPIは、ほぼ全てbytearray型オブジェクトを受け入れます。

The mutable API is based on collections.MutableSequence . 
可変型に対応するAPIは、collections.MutableSequenceに基づいています。

* All backslashes in raw string literals are interpreted literally. This means that '\U' and '\u' escapes in raw strings are not treated specially.
raw文字列リテラル内のすべてのバックスラッシュ(日本語コードでは\)は、文字通りに解釈されます。つまり'\U'と'\u'も、raw文字列の中では特別扱いされません。

For example, r'\u20ac' is a string of 6 characters in Python 3.0, whereas in 2.6, ur'\u20ac' was the single “euro” character.
例えば、Python 2.6ではur'\u20ac'は１文字の『ユーロ記号（Ｃに＝のアレ）』であるのに対して、r'\u20ac'はPython 3.0では（文字どおり）６文字（扱い）です。

 (Of course, this change only affects raw string literals; the euro character is '\u20ac' in Python 3.0.)
（もちろん、この変更はraw文字列だけに影響を与えます。『ユーロ記号』文字列は、Python 3.0でも'\u20ac'で表せます）

* The builtin basestring abstract type was removed.
組み込みのbasestring抽象型は削除されました。

Use str instead.
かわりにstr型を使用してください。

（訳注：basestring型は、2.xでは8bit専用だったstr型とUnicode文字列を統合的に扱うために存在しました）

The str and bytes types don’t have functionality enough in common to warrant a shared base class.
str型とbytes型は、基底クラスを共有するほどの共通機能を持っていません。

The 2to3 tool (see below) replaces every occurrence of basestring with str .
2to3ツール（下記参照）は、basestring型の全ての事項をstr型に置き換えます。

* Files opened as text files (still the default mode for open() ) always use an encoding to map between strings (in memory) and bytes (on disk).
ファイルをテキストファイルとして開く(open関数のデフォルトのモード)時は常に、文字列(メモリ上)とバイト列(ディスク上)の間の対応のためにエンコーディングを行います。

Binary files (opened with a b in the mode argument) always use bytes in memory.
バイナリファイル（a,b モード引数を使用して開いた）は常にメモリ内のバイト列を使用します。

This means that if a file is opened using an incorrect mode or encoding, I/O will likely fail loudly, instead of silently producing incorrect data.
つまり、もし、ファイルを開く時に不正なモードまたはエンコードが使用されると、I/Oは静かに不正なデータを作るかわりに、おそらく派手に失敗します。

It also means that even Unix users will have to specify the correct mode (text or binary) when opening a file.
また、 Unixのユーザでも（テキストまたはバイナリ）のファイルを開くときには、正しいモードを指定する必要があることを意味します。

There is a platform-dependent default encoding, which on Unixy platforms can be set with the LANG environment variable (and sometimes also with some other platform-specific locale-related environment variables).
UNIX型プラットフォームに於いては、LANG環境変数をセットすることができるため、プラットフォーム依存のデフォルトのエンコーディングがあります（そして時には、いくつかの他のプラットフォーム固有のロケールに関連する環境変数によっても……）

In many cases, but not all, the system default is UTF-8; you should never count on this default.
多くの場合システムのデフォルトはUTF-8です……が……しかし、『全て』ではないので、デフォルトを当てにしないでください。 

Any application reading or writing more than pure ASCII text should probably have a way to override the encoding. There is no longer any need for using the encoding-aware streams in the codecs module.
幾つかのアプリケーションは、純粋なASCIIテキストを読み書きする以上にエンコーディングを上書きする方法がおそらくあります。もはやコーデックモジュールでエンコードを意識したストリームを扱う必要はありません。

* Filenames are passed to and returned from APIs as (Unicode) strings. This can present platform-specific problems because on some platforms filenames are arbitrary byte strings.
ファイル名はAPIから(Unicode)文字列として渡され、返されます。これは現在、プラットフォーム固有の問題を生んでいます。なぜなら、いくつかのプラットフォームのファイル名は任意のバイト文字列だからです。

(On the other hand, on Windows filenames are natively stored as Unicode.) As a work-around, most APIs (eg open() and many functions in the os module) that take filenames accept bytes objects as well as strings, and a few APIs have a way to ask for a bytes return value. 
（その一方で、ネイティブのWindowsファイル名をUnicodeとして格納されます)仕事回りでは、殆どのAPI(例えば、open関数やosモジュールの数多くの関数など)は、ファイル名を文字列よりバイト列オブジェクトで受け取ります。そして幾つかのAPIでは、バイト列を戻り値として求める方法があります。

Thus, os.listdir() returns a list of bytes instances if the argument is a bytes instance, and os.getcwdb() returns the current working directory as a bytes instance.
例えば、os.listdir関数は、もし、引き数がbytes型ならば、バイト列のリストを返します。そしてos.getcwdb関数は、現在の作業ディレクトリをバイト列で返します。

Note that when os.listdir() returns a list of strings, filenames that cannot be decoded properly are omitted rather than raising UnicodeError .
os.listdir関数が文字列のリストを戻す時に、適切にデコードされることができないファイル名が、UnicodeErrorを上る場合よりも、『忘れられること』に注意してください。

* Some system APIs like os.environ and sys.argv can also present problems when the bytes made available by the system is not interpretable using the default encoding.
システムによって使用可能にされたバイト列が、デフォルトのエンコーディングを使って、解釈可能でない時、os.environとsys.argvのような幾つかのシステムAPIは、問題をおこす可能性があります。

Setting the LANG variable and rerunning the program is probably the best approach. 
LANG変数を設定し、プログラムを再実行することが、たぶん最もよいアプローチでしょう。

* PEP 3138 : The repr() of a string no longer escapes non-ASCII characters.
* PEP 3138 : 文字列のreprは、もはや非ASCII文字をエスケープしたりしません。

It still escapes control characters and code points with non-printable status in the Unicode standard, however.
しかしながら、ユニコード標準の中で印刷可能でないステータスを持つコードポイントと制御文字は、エスケープされることになります。

* PEP 3120 : The default source encoding is now UTF-8. 
* PEP 3120：デフォルトのソースのエンコードは、現在UTF-8です。

* PEP 3131 : Non-ASCII letters are now allowed in identifiers. (However, the standard library remains ASCII-only with the exception of contributor names in comments.) 
* PEP 3131 : 非ASCII文字でも識別子として使えます（ただし、標準ライブラリでは、コメント欄の寄稿者の名前を除き、ASCIIのみが許可されています ）

* The StringIO and cStringIO modules are gone. 
* StringIOとcStringIOモジュールはなくなりました。

Instead, import the io module and use io.StringIO or io.BytesIO for text and data respectively.
代わりに、ioモジュールをインポートして、io.StrintIOやio.BytesIOを、テキストとデータにそれぞれ使用します。

* See also the Unicode HOWTO , which was updated for Python 3.0.
詳しくは、Python 3.0で更新された『the Unicode HOWTO』を参照してください。



Overview Of Syntax Changes
構文の変更点の概要

This section gives a brief overview of every syntactic change in Python 3.0.
このセクションではPython 3.0のすべての統語変化の概要を説明することができます。

New Syntax
新しい構文

* PEP 3107 : Function argument and return value annotations. 
* PEP 3107 ：関数の引数と戻り値の注釈

This provides a standardized way of annotating a function’s parameters and return value.
これは、関数のパラメータや戻り値の注釈に、標準化された方法を提供します。 

There are no semantics attached to such annotations except that they can be introspected at runtime using the __annotations__ attribute.
この注釈をつけることは、__annotations__属性を実行時に内省（自己分析）するのに使用する、などの用途を除き、（機能的には）何の意味も付与しません。

The intent is to encourage experimentation through metaclasses, decorators or frameworks.
その意図は、メタクラス、デコレータ（修飾子）、またはフレームワークを通して実験を奨励することです。

* PEP 3102 : Keyword-only arguments. 
* PEP 3102 ：キーワードのみの引数

Named parameters occurring after *args in the parameter list must be specified using keyword syntax in the call.
パラメータリストの*arg)の後に置かれる名前つきのパラメータは、キーワード構文を使って呼び出すことに特化されています。

（訳注：*argという書式は、それ以降の（特にキーワード指定のない）パラメータをリストとして受け取ります。これ以降の仮引数は、キーワードで指定されない限り、その仮引数に引き渡されません）

You can also use a bare * in the parameter list to indicate that you don’t accept a variable-length argument list, but you do have keyword-only arguments.
関数で可変長引数リストを受け取らないことを示すために、パラメータリストの中で裸の‘*’を使うことができます。ただし、その場合、キーワード（限定）引数を設定する必要があります。

* Keyword arguments are allowed after the list of base classes in a class definition.
キーワード引数が、クラス定義の基底クラスのリストの後に使えるようになりました。

This is used by the new convention for specifying a metaclass (see next section), but can be used for other purposes as well, as long as the metaclass supports it.

これは、メタクラスを指定するための新しい規定によって使われます（次項参照）。ただし、メタクラスがこれをサポートするかぎり、これは他の目的にも同様に使えます。

* PEP 3104 : nonlocal statement.
* PEP 3104 : nonlocal文

Using nonlocal x you can now assign directly to a variable in an outer (but non-global) scope. nonlocal is a new reserved word.
今直接外（ただし、非グローバル）スコープ。非局所的で非局所Xの変数に割り当てることができますを使用して

'nonlocal x'を使うと、あなたは直接外側スコープの変数に代入することができます（でもxはglobalではありません）。'nonlocal'は新しい予約語です。

* PEP 3132 : Extended Iterable Unpacking. 
* PEP 3132 : 拡張された反復可能展開

You can now write things like a, b, *rest = some_sequence .
『a, b, *rest = some_sequence』のような書きかたが可能になりました。

And even *rest, a = stuff.
さらに『*rest, a = stuff』のような書きかたも。

The rest object is always a (possibly empty) list; the right-hand side may be any iterable. 
残りのオブジェクトは常に（ひょっとしたら空の）リストであり、右側は反復可能な（オブジェクトであれば）何でもかまいません。

Example:
例：

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

This sets a to 0 , b to 4 , and rest to [1, 2, 3] .
この書式では、aに0を、bには4に、そしてrestに [1, 2, 3] をセットします。

* Dictionary comprehensions: {k: v for k, v in stuff} means the same thing as dict(stuff) but is more flexible.(This is PEP 0274 vindicated. :-)

辞書の内包表記『{k: v for k, v in stuff}』は、『dict(stuff)』と同等です。しかし、もっと柔軟です(これはPEP 0274を養護しています :-)

（訳注：stuffは『要素』なので、
	((1,100),(2,200))
のようなkey-value対応のモノを想定している。
しかし、たとえばdが辞書ならば、
	x = dict(d)
は通っても
	x = {k: v for k, v in d}
は通らない。この場合、
	x = {k: v for k, v in d.items()}
とする必要がある）