What's New in Python 2.2
************************

著者:
   A.M. Kuchling


はじめに
========

この文書は 2002 年 10 月 14 日にリリースされた Python 2.2.2 の新機能に
ついて解説します。Python 2.2.2 は 2001 年 12 月 21 日にリリースされた
Python 2.2 のバグフィックスリリースです。

Python 2.2 は「クリーンアップリリース」と考えることが出来ます。ジェネ
レータやイテレータのように、完全に書き直されたいくつかの機能があります
。ほとんどのその変更は著しくて以前とはかけ離れたものとなりましたが、こ
れは言語設計の不品行と暗黒面を綺麗に掃除することを目的としています。

このドキュメントは個々の新機能の完全な詳細を提供するのではなくて、簡易
な概要を提供することを目的にしています。完全な詳細が知りたければ、
Python ライブラリリファレンス 、Python リファレンスマニュアル のような
Python 2.2 のドキュメントを参照すべきです。設計と実装の根拠を理解した
い場合は、新機能に関する PEP を参照してください。


PEP 252 と PEP 253: 型とクラスについての変更
============================================

最大にして広範に影響が及ぶ Python 2.2 の変更は、 オブジェクトとクラス
の Python モデルについてのものです。変更は後方互換であるはずなので、あ
なたのコードは変更なしで動きそうです。ですがその変更は、いくつかの素晴
らしい能力を発揮させます。この、本記事中において最も長くて複雑なセクシ
ョンについて始める前に、変更の概要を提供し、いくつかの所感を提示してお
こうと思います。

A long time ago I wrote a web page listing flaws in Python's design.
One of the most significant flaws was that it's impossible to subclass
Python types implemented in C.  In particular, it's not possible to
subclass built-in types, so you can't just subclass, say, lists in
order to add a single useful method to them. The "UserList" module
provides a class that supports all of the methods of lists and that
can be subclassed further, but there's lots of C code that expects a
regular Python list and won't accept a "UserList" instance.

Python 2.2 はこれを修正し、また、その過程においていくつかの心躍る新機
能を追加しました。簡単に要約します:

* あなたはリストのような組み込み型をサブクラス化出来ます。整数でさえ出
  来ます。そしてあなたのサブクラスは、元の型を要求している全ての場所で
  動作します。

* 以前より使えたインスタンスメソッド加え、静的メソッド、クラスメソッド
  を今や定義出来ます。

* *properties* と名付けられた新しい機構を使うと、インスタンスの属性へ
  の参照または設定時に自動的にメソッドを呼び出すようにも出来ます。従来
  の "__getattr__()" の多くの用法は properties を使って書き換えること
  が出来、それはまたコードを単純にし、高速化もします。小さなオマケとし
  て、属性にも docstring を持てるようになりました。

* *slots* を使って、インスタンスの適正な属性を特定の集合に制限できます
  。これはタイプミスに対する安全装置にも出来ますし、将来のバージョンの
  Python では今よりも最適化される可能性があります。

一部のユーザはこれら全ての変更に懸念を表明しました。そうだね、彼らは言
います、新しい機能はかっこいいし昔の Python では出来なかった全ての芸当
の役に立つさ、だけどさ、それって言語をより複雑にするよなぁ。一部の人々
はずっと常に、Python が単純さを保つことを提言してきました。そして彼ら
はその単純さが失われると感じたのです。

個人的に私は、それらは心配には及ばない、と思っています。多くのそれら新
機能は随分と秘伝的で、あなたはそれらに気付く必要もないままたくさんの
Python コードを書けます。単純なクラスを書くことはかつてよりも難しいと
いうことはなく、実際にそれを必要としない限りは、秘伝をわざわざ学習する
ことも教育することも必要ありません。以前ならば C 言語からでしか可能で
なかったようなある種の複雑なタスクは、いまやピュアな python から出来て
、私には何もかもが良い方向に思えます。

この記事では全てのショーケースの品を陳列しようとはしませんし、将来の拡
張のために必要な小さな変更は説明しません。代わりにこのセクションではお
おまかなアウトラインを描きます。Python 2.2 の新しいオブジェクトモデル
の追加的な情報源については、 関連リンク を参照してください。


旧と新クラス
------------

まず、 Python 2.2 は本当に 2 種類のクラスを持っているのだ、ということ
を知る必要があります: クラシック、あるいは旧スタイルクラス、と、新スタ
イルクラスです。旧スタイルクラスのモデルは、以前のバージョンのクラスモ
デルと完全に同じものです。このセクションに記述する全ての新機能は、全て
新スタイルクラスだけに適用されるものです。この逸脱が未来永劫続くことは
望まれていません; 最終的には旧スタイルクラスは撤廃されます。たぶん
Python 3.0 で。

では、新スタイルクラスは、どうやって定義すればいいのでしょう? 答えは、
既存の新スタイルクラスをサブクラス化することです。たとえば整数、リスト
、辞書やファイルでさえも、ほとんどの Python 組み込み型は今では新スタイ
ルクラスです。 "object" という名の新スタイルクラスは全ての組み込み型の
基底クラスとして既に追加されていて、相応しい組み込み型がなければ単に
"object" をサブクラス化すれば良いです:

   class C(object):
       def __init__ (self):
           ...
       ...

これは、Python 2.2 では、基底クラスを持たない "class" 文はいつでも旧ス
タイルクラスになることを意味します。(実際には、モジュールレベルの変数
"__metaclass__" をセットすることでこれは変更出来ます --- 詳細は **PEP
253** 参照 --- ですが "object" をサブクラス化する方が簡単です。)

組み込み型(ビルトイン型)のための型オブジェクトは、クレバーなトリックを
使って名付けられた組み込み(ビルトイン)として利用可能です。Python は既
に組み込み関数 "int()", "float()", "str()" を持っていました。2.2 には
その関数はなくなり、型オブジェクトは呼び出されるとファクトリとして振舞
います:

   >>> int
   <type 'int'>
   >>> int('123')
   123

型の集合を完全にするために、 "dict()" や "file()" のような新しい型オブ
ジェクトが追加されました。もっと面白い例を挙げておきましょう。以下はフ
ァイルオブジェクトに "lock()" メソッドを追加します:

   class LockableFile(file):
       def lock (self, operation, length=0, start=0, whence=0):
           import fcntl
           return fcntl.lockf(self.fileno(), operation,
                              length, start, whence)

今は撤廃された "posixfile" モジュールにはファイルオブジェクトのメソッ
ドを全てエミュレートしつつ "lock()" を追加しているクラスが含まれていま
すが、このクラスは組み込み型のファイルオブジェクトを期待する内部関数に
渡すことが出来ません。私たちの新しい "LockableFile" ではそれが出来ます
。


デスクリプタ
------------

以前のバージョンの Python には、オブジェクトによってサポートされている
属性とメソッドがなんなのかを見つけ出すための一貫した方法はありませんで
した。 "__members__" と "__methods__" で名前のリストを公開するといった
非公式な慣習は存在してはいましたが、拡張型やクラスの作者はわざわざそれ
らを定義しないということは、ままありました。一歩後退してオブジェクトの
"__dict__" を調べられたとしても、クラスが継承や任意の "__getattr__()"
フックを使っていたりすれば、これはなお不正確になりえました。

その新しいクラスモデルの根底にあったひとつの大きな着想は、
*descriptors* を使ったオブジェクトの属性を記述する API を正式なものに
してしまうことです。デスクリプタは属性の値を記述し、それがメソッドなの
かフィールドなのかを伝えます。デスククリプタ API によって、静的メソッ
ドとクラスメソッドが、より風変わりなコンストラクタとともに可能となりま
した。

属性デスクリプタはクラスオブジェクト内部に棲息するオブジェクトで、それ
自身のいくつかの属性を持っています:

* "__name__" は属性の名前です。

* "__doc__" は属性の docstring です。

* "__get__(object)" は *object* から属性値を取り出すメソッドです。

* "__set__(object, value)" は *object* の属性に  *value* をセットする
  メソッドです。

* "__delete__(object, value)" は *object* の *value*  属性を削除します
  。

例えば、あなたが "obj.x" と書いたときに Python が実際に行うことは以下
です:

   descriptor = obj.__class__.x
   descriptor.__get__(obj)

メソッドに対しては、 "descriptor.__get__()" は、そのインスタンスとその
上で呼び出されるメソッドをまとめた、呼び出し可能な一時オブジェクトを返
します,これはどうして静的メソッドとクラスメソッドが今や可能となったの
か、の理由でもあります; それらは各々、メソッドだけ、メソッドとクラスを
まとめる、とするデスクリプタを持っているのです。これら新種のメソッドの
簡単な説明としては、静的メソッドはインスタンスを渡さないので、普通の関
数に似ていて、クラスメソッドはオブジェクトそのものではなくクラスを渡し
ます。静的メソッドとクラスメソッドはこのように定義します:

   class C(object):
       def f(arg1, arg2):
           ...
       f = staticmethod(f)

       def g(cls, arg1, arg2):
           ...
       g = classmethod(g)

"staticmethod()" 関数は関数 "f()" を引数に取り、デスクリプタにまとめあ
げて返しますので、クラスオブジェクト内に格納出来ます。きっとあなたがそ
のようなメソッドを作る何か特別な文法を期待するでしょう("def static f",
"defstatic f()" みたいな、あるいはそんななにか)が、まだありません; 将
来バージョンの Python に期待、です(訳注: Python 2.4 で PEP 318 として
実現)。

スロットとプロパティのような新機能がさらに新種のデスクリプタとして実装
され、また、何か奇抜なデスクリプタクラスを書くことは難しくはありません
。例えば、Eiffel 言語スタイルのメソッドに対する事前条件・事後条件を書
くことを可能とするデスクリプタクラスを書けるかもしれません。それを使っ
たクラスはきっとこう定義出来るでしょう:

   from eiffel import eiffelmethod

   class C(object):
       def f(self, arg1, arg2):
           # The actual function
           ...
       def pre_f(self):
           # Check preconditions
           ...
       def post_f(self):
           # Check postconditions
           ...

       f = eiffelmethod(f, pre_f, post_f)

新しい "eiffelmethod()" を使う人にとっては、デスクリプタについての何ら
かも理解する必要がないことに注目してください。これが私が新機能が言語の
基本的な複雑さを増さないのだと考える理由です。例えば "eiffelmethod()"
やら ZODB やらなんやらを書くためにそれを知る必要がある、限られた陰陽道
使いがいるということです。そして大半のユーザは出来上がったライブラリの
頂上部を使ってコードを書くだけのことで、実装の詳細なんかは気にしません
。


多重継承: ダイヤモンドルール
----------------------------

多重継承は名前解決のルールの変更を経てより有用なものになっています。ク
ラスのこのようなセットを考えてみましょう (ダイアグラムは Guido van
Rossum による **PEP 253** より):

         class A:
           ^ ^  def save(self): ...
          /   \
         /     \
        /       \
       /         \
   class B     class C:
       ^         ^  def save(self): ...
        \       /
         \     /
          \   /
           \ /
         class D

クラシッククラスでの探索ルールは単純ですがあまりスマートではありません
; 基底クラスは深さ優先で左から右へ検索されます。 "D.save()" への参照は
"D", "B", "A" と辿って "save()" が見つかるのでこれが返ります。
"C.save()" はまったく見つけられることはありません。これはよくありませ
ん。"C" の "save()" が仮に何か "C" に固有な状態を保存するのだとしたら
、これを呼ばないことはその状態が決して保存されないことに繋がります。

新スタイルクラスはちょっと説明するのに複雑な違ったアルゴリズムを使い、
この状況では正しいことをします(Python 2.3 ではこのアルゴリズムはさらに
変更されて、ほとんどのケースで同じ結果となり、本当に複雑な継承グラフの
場合にもっと有用な結果となりました)。

1. 基底クラス全てを、クラシックな検索ルールに従って検索し、繰り返し訪
   れるなら複数回含めます。上の例の場合は訪問クラスのリストは ["D",
   "B", "A", "C", "A"] となります。

2. リストから重複クラスを探します。もしあれば、 *最後* に現れる一つだ
   け残して全て削除します。上の例の場合、リストは重複削除後 ["D", "B",
   "C", "A"] になります。

このルールに従うと "D.save()" 参照は "C.save()" を返します。これが我々
が望んだ振る舞いです。この探索ルールは Common Lisp に倣ったものです。
新しい組み込み関数 "super()" は Python のアルゴリズムを再実装する必要
なくクラスのスーパークラスを得る手段を提供します。その最も一般的な用法
は "super(class, obj)" とすることで束縛されたスーパークラスのオブジェ
クト(実際のクラスオブジェクトではなく)を取得することです。この形式はス
ーパークラス内のメソッドを呼び出すメソッドで使われるでしょう。例えば
"D" の "save()" メソッドはこのように呼び出すことが出来ます:

   class D (B,C):
       def save (self):
           # Call superclass .save()
           super(D, self).save()
           # Save D's private information here
           ...

"super()" は "super(class)" や "super(class1, class2)" のように呼ばれ
れば非束縛のスーパークラスオブジェクトも返せますが、これはあまり役には
立たないでしょう。


属性アクセス
------------

かなりの数の洗練された Python クラスが、 "__getattr__()" を使って属性
アクセスのフックを定義しています; もっとも一般的なのは、 "obj.parent"
のような属性アクセスを "obj.get_parent" のようなメソッド呼び出しに自動
的にマッピングすることによって、コードを読みやすくするための便宜として
です。Python 2.2 は属性アクセスをコントロールする新しい方法を追加しま
した。

まず、 "__getattr__(attr_name)" は新スタイルクラスにおいてもなおサポー
トされ、変更はありません。これまで同様に、 "obj.foo" アクセスが試みら
れて、インスタンスの辞書に "foo" 名の属性が見つからなければ呼び出され
ます。

新スタイルクラスでは新しいメソッド "__getattribute__(attr_name)" もサ
ポートされます。 2 つのメソッドの違いは、古いほうの "__getattr__()" が
"foo" がインスタンスの辞書に見つからなかった場合のみ呼ばれる一方で、
"__getattribute__()" は任意の属性アクセスがあればいつでも *常に* 呼び
出されることです。

しかしながら、Python 2.2 の *properties* サポートは、しばしば属性参照
をトラップするより簡単な方法になります。 "__getattr__()" メソッドの記
述が複雑になるのは、再帰を避けるために内部では普通の属性アクセスが出来
ず、代わりに "__dict__" の中身をもてあそぶ必要があるからです。
"__getattr__()" メソッド は、 "__repr__()" や "__coerce__()" のような
ほかのメソッドのためにチェックするのにも結局 Python によって呼び出され
るので、これを念頭に置いて書かなければなりません。挙句、属性アクセスの
たびに毎回関数を呼び出すことは、かなり大きなパフォーマンスロスに繋がり
ます。

"property" は新しい組み込み型で、属性の get, set, delete の 3 つの関数
と docstring を梱包したものです。例えば、計算で求まるけれども設定も出
来る "size" 属性を定義したいとすると、このように書けます:

   class C(object):
       def get_size (self):
           result = ... computation ...
           return result
       def set_size (self, size):
           ... compute something based on the size
           and set internal state appropriately ...

       # Define a property.  The 'delete this attribute'
       # method is defined as None, so the attribute
       # can't be deleted.
       size = property(get_size, set_size,
                       None,
                       "Storage size of this instance")

これは確実に、より明快であり書くのが容易です。
"__getattr__()"/"__setattr__()" メソッドのペアでは、全てのほかの属性を
インスタンスの "__dict__" から抽出しながら "size" 属性を特別に処理しな
ければならないところでした。"size" へのアクセス時に行われるのは仕掛け
た関数を呼び出すことだけなので、ほかの属性への参照が速度を落とすことは
ありません。

もう一つ最後、新しいクラス属性 "__slots__" を使うと、オブジェクトで参
照出来る属性リストを制約することが出来ます。Python オブジェクトは普通
非常に動的で、どんなときにもインスタンスに対して単に "obj.new_attr=1"
とするだけで新しい属性を定義出来ます。新スタイルクラスは "__slots__"
という名前のクラス属性を定義出来、これにより適正な属性名集合を特定の集
合に制限出来ます。実例をみるのが早いです:

   >>> class C(object):
   ...     __slots__ = ('template', 'name')
   ...
   >>> obj = C()
   >>> print obj.template
   None
   >>> obj.template = 'Test'
   >>> print obj.template
   Test
   >>> obj.newattr = None
   Traceback (most recent call last):
     File "<stdin>", line 1, in ?
   AttributeError: 'C' object has no attribute 'newattr'

"__slots__" リストに含めなかった属性への代入を試みて "AttributeError"
になっていることに注目してください。


関連リンク
----------

このセクションは新機能について、あなたがプログラミングを始める説明とし
ては十分な簡単な概要だけ示しました。ですが、多くの詳細は、単純化したり
無視しています。もっと完全な光景を眺めたければ、どこに行けば良いでしょ
うか?

The デスクリプタ HowTo ガイド is a lengthy tutorial introduction to
the descriptor features, written by Guido van Rossum. If my
description has whetted your appetite, go read this tutorial next,
because it goes into much more detail about the new features while
still remaining quite easy to read.

次です。2 つの関連する PEP、 **PEP 252**, **PEP 253** があります。
**PEP 252** は "型をもっとクラスに似せる(Making Types Look More Like
Classes)" というタイトルで、デスクリプタ API についてカバーしています
。 **PEP 253** は "組み込み型のサブタイプ化(Subtyping Built-in Types)"
というタイトルで、組み込み型のサブタイプを可能とするための型オブジェク
トの変更について記述しています。 **PEP 253** は 252 よりも複雑な PEP
で、型とメタ型で必要な説明のいくつかのポイントでは、あなたの脳味噌は爆
発するかもしれないです。どちらの PEP も、著・実装ともに、Zope Corp. チ
ームの残りのメンバーからのかなりの支援を受けて、Guido van Rossum によ
って書かれました。

最後ですが、究極の権威があります: ソースコードです。型ハンドリングのほ
とんどの機構は "Objects/typeobject.c" 内にあります。ただしこれに頼るの
は、python-list や python-dev へ質問を投稿することを含むほかの全ての手
段を使い果たしたのちの最後の手段にしてください。


PEP 234: イテレータ
===================

2.2 でのもう一つの重要な追加は、C と Python レベル両方に対するイテレー
ションインターフェイスです。オブジェクトが呼び出し元からどのように反復
されるのか定義出来ます。

2.1 までの Python では "for item in obj" が動作するようにするための手
段は普通、 "__getitem__()" メソッドをおよそこのような具合に定義するこ
とです:

   def __getitem__(self, index):
       return <next item>

"__getitem__()" はもっと相応しい用途、つまり 6 番目の要素を取り出すた
めに "obj[5]" と書くことが出来るようにオブジェクトへの添え字操作を定義
するのに使うものです。 "for" ループをサポートするためだけにこれを使う
ことは、少しばかり人を欺いてしまいます。なにかファイルのように振舞うオ
ブジェクトを巡回出来るようにしたいとしましょう; *index* パラメータは本
質的に無意味です。そのクラスはおそらく "__getitem__()" 呼び出しの連続
で呼ばれるたびに *index* を加算して然るべきだと考えるでしょう。言い換
えれば、 "__getitem__()" の存在はランダムに "file[5]" を使って 6 番目
の要素にアクセス出来ることを意味しません、本来そうであるべきなのに。

Python 2.2 においては、イテレーションは分けて定義出来ます。
"__getitem__()" メソッドは本当にランダムアクセスをサポートしたいクラス
だけが使えば良いです。イテレータの基礎的なアイディアは単純です。新しい
ビルトイン関数 "iter(obj)" または "iter(C, sentinel)" は、イテレータを
取り出すのに使います。 "iter(obj)" はオブジェクト  *obj* についてのイ
テレータを返し、 "iter(C, sentinel)" は、そのイテレータが完了を表明す
る *sentinel* を返すまで呼び出し可能オブジェクト *C* を呼び続けるイテ
レータを返します。

Python クラスはオブジェクトの新しいイテレータを構築して返す
"__iter__()" メソッドを定義出来ます; そのオブジェクト自身が自身のイテ
レータであれば、このメソッドは単に "self" を返すだけで良いです。特に、
イテレータは普通自身へのイテレータです。C で実装される拡張型はイテレー
タを返すために "tp_iter" 関数を実装出来、イテレータとして振舞いたい拡
張型は、 "tp_iternext" 関数を実装出来ます。

それでは、結局のところイテレータは実際どんなでしょうか? これに必要なメ
ソッドは一つ、 "next()" です (---訳注: Python 3 で "__next__" に変更さ
れています---)。これは引数を取らず、次の値を返します。返すべき値がなく
なったら、 "next()" 呼び出しは "StopIteration" 例外を送出しなければな
りません:

   >>> L = [1,2,3]
   >>> i = iter(L)
   >>> print i
   <iterator object at 0x8116870>
   >>> i.next()
   1
   >>> i.next()
   2
   >>> i.next()
   3
   >>> i.next()
   Traceback (most recent call last):
     File "<stdin>", line 1, in ?
   StopIteration
   >>>

2.2 では、Python の "for" ステートメントはもはやシーケンスであることを
要求しません; それは "iter()" がイテレータを返す何かであれば良いです。
後方互換と便宜のために、 "__iter__()" や "tp_iter" スロットを実装しな
いシーケンスについては、自動的にイテレータが構築されるので、 "for i in
[1,2,3]" はそのまま動きます (---訳注: 2.2 時点では list に "__iter__"
が実装されていなかったのかもしれませんが、以降の What's New に明示はな
いものの、少なくとも 2.7 の list はイテレータプロトコルを実装していま
す。---)。Python インタプリタがシーケンスを反復する場合にはいつでも、
それはイテレータプロトコルの使用に変換されます。つまりこんなことが出来
るということです:

   >>> L = [1,2,3]
   >>> i = iter(L)
   >>> a,b,c = i
   >>> a,b,c
   (1, 2, 3)

いくつかの Python の基礎型には既にイテレータのサポートが追加されていま
す。辞書に対して "iter()" を呼び出すと、キーの反復をするイテレータが返
ります:

   >>> m = {'Jan': 1, 'Feb': 2, 'Mar': 3, 'Apr': 4, 'May': 5, 'Jun': 6,
   ...      'Jul': 7, 'Aug': 8, 'Sep': 9, 'Oct': 10, 'Nov': 11, 'Dec': 12}
   >>> for key in m: print key, m[key]
   ...
   Mar 3
   Feb 2
   Aug 8
   Sep 9
   May 5
   Jun 6
   Jul 7
   Jan 1
   Apr 4
   Nov 11
   Dec 12
   Oct 10

"iter()" がキーでの反復イテレータを返すのはただのデフォルトの振る舞い
です。キーで、値で、キーと値のペアで反復したければ、 "iterkeys()",
"itervalues()", "iteritems()" で適切なイテレータを取れます (---訳注:
Python 3 では対応するメソッド名が "keys", "values", "items" に変わった
だけでなく、これらは「ビュー」オブジェクトを返すように変更されています
。---) ほかに小さな変更点としては、 "in" 演算子は今では辞書に対して動
作し、 "key in dict" は "dict.has_key(key)" と等価です (---訳注:
Python 3 では辞書オブジェクトのメソッド "has_key" はなくなり、 "key in
dict" がキー有無を直接問い合わせる唯一の方法です---)。

ファイルもイテレータを提供しています。これはファイルに読むべき行がなく
なるまで "readline()" を呼び出すもので、つまりファイルを行ごとに読み出
すのにこのように書けるわけです:

   for line in file:
       # do something for each line
       ...

イテレータは前進しか出来ないことに注意してください; 前の要素を取り出す
手段もなければ、イテレータをリセットしたりコピーしたりといったことも出
来ません。イテレータオブジェクトにそのような追加の能力を持たせることは
出来ますが、イテレータプロトコルが規定するのは "next()" メソッドのみで
す。

参考:

  **PEP 234**: イテレータ
     著: Ka-Ping Yee と GvR (Guido van Rossum); 実装: Python Labs クル
     ー, 主に GvR と Tim Peters.


PEP 255: 単純なジェネレータ
===========================

ジェネレータはもう一つの新機能で、これはイテレータの導入と連携するもの
です。

Python や C の標準的な関数コールについては、よくご存じに違いありません
。関数を呼ぶと、ローカル変数を作るプライベートな名前空間ができますね。
その関数が "return" 文まで来ると、ローカル変数が破壊されてから、返り値
が呼び出し元に返ります。次に同じ関数をもう一度呼ぶと、新しいプライベー
ト名前空間に新規のローカル変数が作られるのです。しかし、関数を出るとき
にローカル変数を捨てなければどうなるでしょうか。その出ていったところか
ら関数を続行できたとしたら、どうでしょう。これこそジェネレータが提供す
る機能です; すなわち、ジェネレータは続行できる関数と考えることができま
す。

ジェネレータ関数の最も単純な例です:

   def generate_ints(N):
       for i in range(N):
           yield i

新しいキーワード "yield" がジェネレータのために導入されました。
"yield" ステートメントを含むどんな関数もジェネレータ関数です; Python
バイトコードコンパイラはこれを検知し、関数が特別に扱われるように翻訳し
ます。新たなキーワードの導入なので、ジェネレータを使えるようにするには
"from __future__ import generators" ステートメントをモジュールソースコ
ードの先頭付近に含めなければなりません。Python 2.3 ではこのステートメ
ントは不要になります。(---訳注: Python 2.5 の PEP 342 も参照して下さい
。この 2.2 で導入時点の "yield" はステートメントではなく式に変更されて
います。---)

ジェネレータ関数を呼び出すと、単一の値の代わりにイテレータプロトコルに
対応したオブジェクトを返します。上の例で "yield" を実行したとき、ジェ
ネレータは "return" 文のようにして "i" の値を生成します。 "yield" と
"return" 文の大きな違いは、 "yield" に到達した段階でジェネレータの実行
状態が一時停止になって、ローカル変数が保存される点です。次回そのジェネ
レータの ".next()" メソッドを呼ぶと、 "yield" の直後から関数が実行を再
開します。(複雑な理由により、 "yield" は "try"..."finally" の "try" ブ
ロック内に含めることは許されていません; **PEP 255** に "yield" と例外
の相互作用についての詳細説明がありますので参照して下さい。) --- (---訳
注: Python 2.5 の PEP 342 で "try"..."finally" 内に置けないという制約
はなくなりました。また、 "try"..."finally" の "try" 、とここであえて特
定しているのは、同じく 2.5 の PEP 341 によって try/except/finally の一
体化されるまでは、 "finally" の "try" と "except" の "try" が別物だっ
たからです。---)

上記 "generate_ints()" ジェネレータはこんな具合に使います:

   >>> gen = generate_ints(3)
   >>> gen
   <generator object at 0x8117f90>
   >>> gen.next()
   0
   >>> gen.next()
   1
   >>> gen.next()
   2
   >>> gen.next()
   Traceback (most recent call last):
     File "<stdin>", line 1, in ?
     File "<stdin>", line 2, in generate_ints
   StopIteration

同じく "for i in generate_ints(5)" や "a,b,c = generate_ints(3)" とい
った書き方もできます。

ジェネレータ関数内で "return" 文は、引数を付けずに、処理の終わりを知ら
せるためにだけ使うことができます; "return" を実行したあとは、もうその
ジェネレータが値を返すことはできません。ジェネレータ関数の中では、
"return 5" などと値を付けた "return" は構文エラーです。ジェネレータの
出力が終わったことを示すには、ほかにも、手動で "StopIteration"  を投げ
てもいいですし、関数の最後まで実行するだけでも同じことになります。(---
訳注: Python 2.7 まではジェネレータ内での戻り値のある "return 5" は構
文エラーになりますが、少なくとも Python 3.4 で構文エラーとはなりません
。単に無視されます。リファレンスに言及されていない振舞いなので、何かの
事故かもしれません。いずれにせよジェネレータ内では Python 3 でも
"return" で値は戻せません。---)

自分でクラスを書いて、ジェネレータで言うところのローカル変数をインスタ
ンス変数として全部保管しておけば、同じ効果を得ることは可能です。たとえ
ば整数のリストを返すのは、 "self.count" を 0 にして、 "next()" メソッ
ドが "self.count" をインクリメントして返すようにすればできます。しかし
ながら、ある程度複雑なジェネレータになってくると、同じことをするクラス
を書くのは格段にややこしいことになります。
"Lib/test/test_generators.py" にはもっと面白い例がたくさん含まれていま
す。一番単純な一つは、ジェネレータを再帰的に使ってツリーを順繰りに横断
する実装をするこれです (---訳注: ジェネレータは現在の最新 3.5 までの間
に 2 度大きな機能強化が行われているのですが、一つが 2.5 での PEP 342
でこれは yield 「に」値を戻せるようにするものです。もう一つが 3.3 での
PEP 380 で、これはサブジェネレータへの委譲 "yield from <subgen>" の追
加でした。ですのでこの 3.3 からの "yield from" を使うと下記例はもっと
スッキリ書けます。---):

   # A recursive generator that generates Tree leaves in in-order.
   def inorder(t):
       if t:
           for x in inorder(t.left):
               yield x
           yield t.label
           for x in inorder(t.right):
               yield x

ほかにも "Lib/test/test_generators.py" には、N-Queens 問題 (N×N コマの
チェス盤に、互いに攻撃できないような配置で N 個のクイーンを置く) やナ
イト・ツアー (N×N 盤の全コマをナイトが一度ずつ通るような経路を探す) の
解を出す例が入っています。

ジェネレータの発想はほかのプログラミング言語、特に Icon
(https://www.cs.arizona.edu/icon/) から着想しています。Icon ではジェネ
レータが言語の中枢になっています。Icon では、あらゆる式と関数がジェネ
レータのように振舞います。
https://www.cs.arizona.edu/icon/docs/ipd266.htm の "Icon プログラミン
グ言語の概要" の一つの例が、これがどのようなものであるのかを教えてくれ
ます:

   sentence := "Store it in the neighboring harbor"
   if (i := find("or", sentence)) > 5 then write(i)

Icon では "find()" 関数は部分文字列 "or" が見つかる位置 3, 23, 33 を返
します。 "if" 文内では "i" には最初 3 が代入されますが、これは 3 より
小さいので比較は失敗し、Icon は次の値 23 を取り出します。 23 は 5 より
大きいので比較は成功し、コードは 23 をスクリーンに表示します。

Python では Icon がそうするほどにはジェネレータを中心的概念に置きませ
ん。ジェネレータは Python 言語中核の新たな一面ではありますが、それらを
学ぶのも使うのも誰しも行うべきだというものでもなく、そしてこれで解決で
きない何か問題があれば、忘れてしまっても良いものです。Icon と比較した
特筆すべき Python インターフェイスの機能はジェネレータの状態が具象オブ
ジェクト (イテレータ) で表現されることであり、それは他の関数に渡せます
し、データ構造に記憶しておくことも出来ます。(---訳注: ジェネレータにつ
いてかなり控えめなのは、この時点で著者は将来の拡張を既に見据えていたか
ら? かもしれませんね。PEP 342 と PEP 380 により今やジェネレータはこの
頃より遥かに高機能になっており、今ではきっと「こんなものなくても困らな
い」なんて Python 使いはいないでしょう。---)

参考:

  **PEP 255** - 単純なジェネレータ
     Neil Schemenauer, Tim Peters, Magnus Lie Hetland により著されまし
     た。実装のほとんどは Neil Schemenauer と Tim Peters により行われ
     、 Python Labs クルーにより他の修正が行われました。


PEP 237: 長整数と整数を一体化していく
=====================================

最近のバージョンでは、普通の整数、これはほとんどの機器で 32 ビットの値
ですが、これと長整数、こちらは任意サイズになりえます、この 2 つの区別
が、苛立ちの種になってきています。たとえば "2**32" より大きなファイル
をサポートするプラットフォームでは、ファイルオブジェクトの "tell()" メ
ソッドは長整数で値を返さなければなりません。しかしながら Python の様々
な場所では無印の整数を期待していて、長整数を渡すと例外を引き起こすので
した。例えば Python 1.5 ではスライスのインデクスとして普通の整数しか使
えず、 "'abc'[1L:]" は 'slice index must be int' というメッセージとと
もに "TypeError" を引き起こしました。

Python 2.2 は必要に応じて short 整数を長整数に値をシフトします。 'L'
サフィックスは長整数リテラルを示すのにはもはや不要です。今ではコンパイ
ラは相応しい型を選べます。('L' サフィックスは将来の Python 2.x では非
推奨となり、Python 2.4 では警告となり、おそらく Python 3.0 では削除さ
れます。 --- 訳注: Python 3 で 'L' が廃止されて、付けると構文エラーに
なるようになったのは事実です。ですが少なくとも Python 2.7 では "-3" で
も "-Qwarnall" でも警告とならないので注意してください。Python 2 系を使
っていて Python 3 との互換性を持ちたいならば、 2.2 以降では 'L' は付け
るべきではありません。 --- ) かつて "OverflowError" となっていたような
多くの演算が、今ではその結果として長整数を返します。例えば:

   >>> 1234567890123
   1234567890123L
   >>> 2 ** 64
   18446744073709551616L

ほとんどのケースで、今や整数と長整数は同じものとして扱われるでしょう。
"type()" ビルトインで今でも区別出来ますが、ほとんど必要ないでしょう
(--- 訳注: Python 3 では本当にこの2つの区別がなくなったので、当然区別
出来ません。Python 3 系への移行を考えている Python 2 コードは、両者の
区別に頼らないようにするべきです。 ---)。

参考:

  **PEP 237** - 長整数と整数を一体化していく
     Moshe Zadka と Guido van Rossum 著、実装 (ほぼ) Guido van Rossum.
     。


PEP 238: 除算演算子を変更していく
=================================

Python 2.2 の変更で最も物議を醸すものが、Python 誕生時からずっとそうで
あり続けた古い設計の欠陥、これを修正するための取り組み開始の予兆です。
現在の Python の除算演算子 "/" は 2 つの整数引数に対して C 言語の除算
演算子のように振舞います: 端数部があれば切り捨てて整数を結果として返し
ます。例えば "3/2" は 1.5 ではなく 1 で、 "(-1)/2" は -0.5 ではなく -1
です。Python の動的型付けにより演算対象の型がなんなのかを容易には決定
できないくせに 2 つの演算対象の型に依存するので、除算の結果は予想に反
したものとなりうるのです。

(議論の的となるのはこれが *本当の* 設計の欠陥なのかどうかと、果たして
これを修正することで既存のコードを破壊する価値はあるのかどうかです。そ
れは python-dev での終わりのない議論を巻き起こし、2001 年 7 月には
*comp.lang.python* への辛辣な投稿の嵐に突入しました。私はここではどち
らかの側に立って説きつけるつもりはなく、Python 2.2 で何が実現したのか
を記述することだけに専念します。**PEP 238** にはその主張と反対意見の要
約が書かれていますので、そちらをお読みください。)

この変更がコードを破壊しうるために、導入は大変ゆっくり少しずつ進められ
ていきます。Python 2.2 が移行を始めますが、切り替えは Python 3.0 にな
るまで達成させられることはありません。

まず最初に、いくつか **PEP 238** から用語を借りることにします。 "真の
除算 (True division)" とは、プログラマでない人々が一番馴染みのある除算
です。 3/2 は 1.5、1/4 は 0.25、などなど。 "切り捨て除算 (Floor
division)" は、整数の被演算子が与えられたときの Python の "/" 演算子が
現在やっていることで、結果は真の除算の結果の値の小数点以下を小さくなる
方向へ丸めたものです。 "クラシック除算 (Classic division)" は現在の
"/" の混合した振る舞いを指します。演算対象が整数同士であれば切り捨て除
算の結果となり、一方が浮動小数点数であれば真の除算の結果となる振る舞い
です。

以下が 2.2 で導入される変更です:

* 新しい演算子 "//" が floor division の演算子です。(いえーい、これっ
  て C++ コメントのシンボルに似てるね、なんてことは私たちは知っていま
  す。) "//" は演算対象の型がなんであれ *いつでも* floor division を実
  行しますので、 "1 // 2" は 0、 "1.0 // 2.0" も 0.0 です。

  "//" は Python 2.2 でいつでも使えます; "__future__" を使って有効化す
  るなんてことは必要ないです。

* "from __future__ import division" をモジュールに import することで、
  "/" 演算子が真の除算 (true division) の結果を返すように変更されるの
  で、 "1/2" は 0.5 になります。 "__future__" 文なしでは "/" はクラシ
  ック除算 (classic division) のままです。 "/" が持つデフォルトの意味
  は Python 3.0 になるまで変更されません。

* クラスでは "__truediv__()" と "__floordiv__()" メソッドを、2つの除算
  演算子をオーバロードするために定義出来ます。C のレベルにも
  "PyNumberMethods" 構造体内にスロットがあり、拡張型もその 2 つの演算
  子を定義出来ます。

* Python 2.2 は、コードが変更後の除算セマンティクスで動作するかどうか
  をテストするコマンドライン引数をサポートします。 "-Q warn" で python
  を実行すると、除算が二つの整数に適用されている箇所全てで警告します。
  除算の意味変更の影響を受ける箇所の特定と修正に使えるでしょう。デフォ
  ルトでは、Python 2.2 は警告なしで単純に classic division を実行しま
  す; その警告がデフォルトになるのは Python 2.3 からです。

参考:

  **PEP 238** - 除算演算子を変更していく
     Moshe Zadka と Guido van Rossum 著、実装 Guido van Rossum.。


Unicode の変更
==============

Python の Unicode サポートが 2.2 で少し拡張されています。Unicode 文字
列は普通は 16 ビット符号なし整数としての UCS-2 で格納されます。Python
2.2 は内部エンコーディングとして 32 ビット符号なし整数の UCS-4 を使う
ようにもコンパイル出来ます。これは **configure** スクリプトに "--
enable-unicode=ucs4" オプションを与えることで行います。("--disable-
unicode" を与えることで完全に Unicode サポートを無効にすることも出来ま
す。)

UCS-4 ("wide Python") を使ってビルドすると、インタプリタは U+000000 か
ら U+110000 までの Unicode 文字をネイティブに処理出来ますので、
"unichr()" 関数へのこの範囲の正当な値は適切に処理されます。UCS-2
("narrow Python") を用いてビルドしたインタプリタの場合は、 65535 を超
える値を "unichr()" に与えるとこれまで通り "ValueError" を投げます。こ
の変更については **PEP 261** 「'wide' Unicode 文字のサポート」に全て記
述されていますので、詳細はこれを調べてください。

もう一つの変更については説明は簡単です。その導入以来 Unicode 文字列は
、文字列を選択した UTF-8 や Latin-1 のようなエンコーディングで変換する
ための "encode()" メソッドをサポートしてきました。2.2 では、対となる
"decode([*encoding*])" メソッドが (Unicode 文字列ではない)  8 ビット文
字列に追加されました。 "decode()" は文字列が特定のエンコーディングであ
ることを仮定してデコードを行い、コーデックにより返されるものを返します
。

この新たなインターフェイスに相乗りする形で、 Unicode には無関係のタス
クのためのコーデックが追加されました。例えば uu エンコーディング、
MIME の base64 エンコーディング、 "zlib" モジュールでの圧縮のためのエ
ンコーディングが追加されています:

   >>> s = """Here is a lengthy piece of redundant, overly verbose,
   ... and repetitive text.
   ... """
   >>> data = s.encode('zlib')
   >>> data
   'x\x9c\r\xc9\xc1\r\x80 \x10\x04\xc0?Ul...'
   >>> data.decode('zlib')
   'Here is a lengthy piece of redundant, overly verbose,\nand repetitive text.\n'
   >>> print s.encode('uu')
   begin 666 <data>
   M2&5R92!I<R!A(&QE;F=T:'D@<&EE8V4@;V8@<F5D=6YD86YT+"!O=F5R;'D@
   >=F5R8F]S92P*86YD(')E<&5T:71I=F4@=&5X="X*

   end
   >>> "sheesh".encode('rot-13')
   'furrfu'

クラスのインスタンスを Unicode に変換するために、クラスに
"__unicode__()" メソッドを定義出来ます。これは "__str__()" への相似で
す。

"encode()", "decode()", "__unicode__()" は Marc-André Lemburg により実
装されました。UCS-4 を内部的に使う変更に関しては Fredrik Lundh と
Martin von Löwis により実装されました。

参考:

  **PEP 261** - 'wide' Unicode 文字のサポート
     Paul Prescod 著。 (---訳注: この What's New セクションと PEP 内容
     は 2.x ではずっと有効ですが、3.x で大幅に変わっていて逐一補足出来
     ないほど大きく違っています。変更の概要についてはクックブックの「
     Python 2 から Python 3 への移植」がわかりやすいと思います。---)


PEP 227: 入れ子状のスコープ
===========================

Python 2.1 では、静的にネストされたスコープが "from __future__ import
nested_scopes" ディレクティブで有効に出来るオプションの機能として追加
されました。2.2 では入れ子のスコープには特別に有効化する必要なく、もう
いつでもそこにあります。このセクションの残りの部分は "What's New in
Python 2.1" の入れ子のスコープの記述からの丸々コピーですので、2.1 のと
きに読んだなら読み飛ばしてもらって結構です。

Python2.1 で導入され、2.2 で完成した最も大きな変更点は Python のスコー
プルールです。Python2.0では、ある指定された時点である変数の名前を検索
するために多くても3つの名前空間、つまりローカル、モジュールレベル、ビ
ルトイン名前空間しか使われませんでした。このことは直感的な期待と一致せ
ずしばしば人々を驚かせました。例えば、入れ子になった再帰関数の定義は動
きません:

   def f():
       ...
       def g(value):
           ...
           return g(value-1) + 1
       ...

名前 "g" はローカルの名前空間にもモジュールレベルの名前空間にも紐付か
ないので、関数 "g()" は常に "NameError" 例外を上げます。これは実際には
大した問題ではありません (このような内部関数を再帰的に定義する頻度はそ
う多くありません)が、 "lambda" 式をより使いにくくするのでこれについて
は問題です。 "lambda" を使うコードにおいて、デフォルトの引数としてこれ
らを渡してコピーされるローカル変数を頻繁に見かけます。:

   def find(self, name):
       "Return list of any entries equal to 'name'"
       L = filter(lambda x, name=name: x == name,
                  self.list_attribute)
       return L

過度な関数型スタイルで書かれた Python コードの可読性は、結果的にはひど
く苦痛を感じるものですね。

Python 2.2 の最も重要な変更点は、この問題を解決するために静的なスコー
プが追加されたことです。最初の効果として、 "name=name" という例ではデ
フォルトの引数は必要ありません。簡単に言えば、指定された引数名が関数内
の値に割り当てられない場合("def" 、 "class" または "import" ステートメ
ントの割り当てによって)、変数の参照は外側のスコープのローカル名前空間
で検索されます。ルールや実装の詳細は PEP で参照できます。

この変更は、同じ変数名がモジュールレベルと関数の定義が含まれている関数
内のローカルの両方で変数名として使用されているコードで、互換性の問題を
引き起こす可能性があります。ですがむしろ気にしなくてよいでしょう。その
ようなコードはそもそも最初から相当こんがらかっているので。

この変更の副作用の一つは、 "from module import *" と "exec" の両ステー
トメントが特定の条件下の関数スコープ内で不正となることです。 Python の
リファレンスマニュアルははじめからずっと "from module import *" はトッ
プレベルモジュールでのみ合法であると言ってきましたが、以前の CPython
インタプリタはこれを一度も強制していませんでした。入れ子になったスコー
プ実装の一環として、Python のソースをバイトコードに変換するコンパイラ
は、内包されたスコープ内の変数にアクセスするために別のコードを生成する
必要があります。 "from module import *", "exec" はコンパイラにこれを理
解することを不可能にしてしまいます。なぜならそれらはコンパイル時にはわ
からないローカル名前空間に名前を追加するからです。それゆえ、もし関数が
関数定義を含んだり自由な変数に "lambda" の語句を含んだりする場合、コン
パイラは "SyntaxError" 例外を上げて知らせます。

前述した説明を少し明確にするため、例を挙げます:

   x = 1
   def f():
       # The next line is a syntax error
       exec 'x=2'
       def g():
           return x

"exec" 文を含む 4 行目は文法エラーです。 "exec" としては新しいローカル
変数 "x" を定義したいのですが、これは "g()" からアクセスされなければな
りません。

これは実際には大した制約でもないはずです。 "exec" が Python コードで使
われるのは稀です(使われているとしたら大抵どこか貧弱な設計であることの
証)。

参考:

  **PEP 227** - 静的に入れ子になったスコープ
     Jeremy Hylton著、実装


新しいモジュールと改良されたモジュール
======================================

* Fredrik Lundh により寄稿された "xmlrpclib" モジュールは、 XML-RPC ク
  ライアントを記述するためのサポートを提供します。XML-RPC は HTTP と
  XML の上に成り立つシンプルなリモートプロシージャコールのプロトコルで
  す。例えば以下のコード断片は O'Reilly ネットワークから RSS チャンネ
  ルのリストを抽出して、一つのチャンネルの最新のヘッドラインをリストし
  ます:

     import xmlrpclib
     s = xmlrpclib.Server(
           'http://www.oreillynet.com/meerkat/xml-rpc/server.php')
     channels = s.meerkat.getChannels()
     # channels is a list of dictionaries, like this:
     # [{'id': 4, 'title': 'Freshmeat Daily News'}
     #  {'id': 190, 'title': '32Bits Online'},
     #  {'id': 4549, 'title': '3DGamers'}, ... ]

     # Get the items for one channel
     items = s.meerkat.getItems( {'channel': 4} )

     # 'items' is another list of dictionaries, like this:
     # [{'link': 'http://freshmeat.net/releases/52719/',
     #   'description': 'A utility which converts HTML to XSL FO.',
     #   'title': 'html2fo 0.3 (Default)'}, ... ]

  "SimpleXMLRPCServer" モジュールは、直裁的な XML-RPC サーバを書くのを
  容易にします。XML-RPC の詳細については  http://xmlrpc.scripting.com/
  を参照して下さい。

* 新しい "hmac" モジュールは、 **RFC 2104** で記述される HMAC アルゴリ
  ズムを実装します 。 (Contributed by Gerhard Häring.)

* 元々が長ったらしいタプルを返していたいくつもの関数が、擬似シーケンス
  を返すように変更されています。変更後もそれはタプルとして振舞いますが
  、例えば memberst_mtime や "tm_year" といった記憶しやすい属性も持ち
  ます。この変更が行われたものには "os" モジュールの "stat()",
  "fstat()", "statvfs()", "fstatvfs()" や "time" モジュールの
  "localtime()", "gmtime()", "strptime()" が含まれます。

  例えば旧式のタプルでファイルサイズを得るには "file_size =
  os.stat(filename)[stat.ST_SIZE]" のように書くしかありませんでしたが
  、今ではもっとわかりやすい "file_size = os.stat(filename).st_size"
  のように書くことが出来ます。

  この機能のオリジナルのパッチは Nick Mathewson により寄稿されました。

* Python プロファイラが大幅に改造されて、出力の色々な間違いが修正され
  ました。 (Contributed by Fred L. Drake, Jr. and Tim Peters.)

* "socket" モジュールを IPv6 サポート付きでコンパイル可能になりました
  。Python の **configure** スクリプトに "--enable-ipv6" オプションを
  与えてください。(Contributed by Jun-ichiro "itojun" Hagino.)

* Two new format characters were added to the "struct" module for
  64-bit integers on platforms that support the C "long long" type.
  "q" is for a signed 64-bit integer, and "Q" is for an unsigned one.
  The value is returned in Python's long integer type.  (Contributed
  by Tim Peters.)

* インタプリタの対話モードに新たに "help()" ビルトインが追加されていま
  す。これは Python 2.1 で導入された "pydoc" モジュールを用いて対話的
  なヘルプを提供します。 "help(object)" で *object* について手に入る任
  意のヘルプを表示します。 "help()" を引数なしで起動するとオンラインの
  ヘルプユーティリティに入ります。ここから関数名やクラス名、モジュール
  名をタイプすることで、それらのヘルプテキストを読むことが出来ます。
  (Contributed by Guido van Rossum, using Ka-Ping Yee's "pydoc"
  module.)

* "re" モジュールのもととなる SRE エンジンに多数のバグフィックスとパフ
  ォーマンス改善がありました。例えば "re.sub()" 関数、 "re.split()" 関
  数が C で書き直されました。もうひとつ、貢献されたパッチが特定の範囲
  の Unicode 文字での 2 倍の高速化を果たし、また新しく、与えられた文字
  列での重ならないマッチ全体を渡るイテレータを返す "finditer()" メソッ
  ドが追加されました。(SRE is maintained by Fredrik Lundh. The
  BIGCHARSET patch was contributed by Martin von Löwis.)

* "smtplib" モジュールに **RFC 2487** 「Secure SMTP over TLS」のサポー
  トが追加されました。これにより Python プログラムとメール転送エージェ
  ント間でのメッセージの暗号化された SMTP トラフィックが可能になりまし
  た。 "smtplib" は SMTP 認証もサポートしています。 (Contributed by
  Gerhard Häring.)

* Piers Lauder によって保守されている "imaplib" モジュールに新たに多く
  の拡張のサポートが追加されました: **RFC 2342** で定義されている
  NAMESPACE 拡張、 SORT、 GETACL、 SETACL。(Contributed by Anthony
  Baxter and Michel Pelletier.)

* email アドレスのパースをする "rfc822" モジュールが **RFC 2822** に準
  拠するようになりました。これは **RFC 822** の更新版です。(モジュール
  名は "rfc2822" には変更 *されません* 。) 新しいパッケージ "email" も
  追加されています。これは e-mail メッセージをパース・生成します。
  (Contributed by Barry Warsaw, and arising out of his work on
  Mailman.)

* "difflib" モジュールに新規クラス "Differ" が追加されています。これは
  テキスト行のシーケンス 2 つについての変更 ("delta") の、人間にとって
  読みやすいリストを生成します。生成関数も 2 つ追加されています。
  "ndiff()" と "restore()" で、前者が 2 つのシーケンスの delta を返し
  、後者が delta から元のシーケンスの一つを返します。 (Grunt work
  contributed by David Goodger, from ndiff.py code by Tim Peters who
  then did the generatorization.)

* "string" モジュールに新規定数 "ascii_letters", "ascii_lowercase",
  "ascii_uppercase" が追加されました。標準ライブラリ内では A-Za-z 範囲
  を意味する "string.letters" がありましたが、この仮定はロケールを使っ
  ている場合は正しくありません。 "string.letters" は現在のロケールで定
  義される合法な文字集合に依存して変化するからです。それら誤ったモジュ
  ールは "ascii_letters" を代わりに用いることで全て修正されました。
  (Reported by an unknown person; fixed by Fred L. Drake, Jr.)

* "mimetypes" モジュールで代替の MIME-type データベースを使うのが簡単
  になりました。 "MimeTypes" クラスがパースされるファイル名のリストを
  取ります。(Contributed by Fred L. Drake, Jr.)

* "threading" モジュールに "Timer" クラスが追加されました。これにより
  ある未来の時間に活性化するようスケジュールすることが出来ます。
  (Contributed by Itamar Shtull-Trauring.)


インタプリタの変更と修正
========================

Python 拡張モジュールを書いたり、インタプリタの埋め込みをしたり、ある
いは単にインタプリタそのものをハックしたりするために C レベルでインタ
プリタを扱う人々以外には影響しないいくつかの変更があります。Python コ
ードを書くだけであればここに記述する変更は、あなたに関係するものは全く
ありません。

* プロファイルとトレースの関数が C で実装されました。Python ベースのも
  のと比較して圧倒的に高速に操作出来、プロファイルとトレースのオーバヘ
  ッドを削減するはずです。これは Python の開発環境の著者に朗報でしょう
  。2 つの C 関数、 "PyEval_SetProfile()" と "PyEval_SetTrace()" が
  Python API に追加されました。既存の "sys.setprofile()" 関数、
  "sys.settrace()" 関数はそのまま存在し、単純に新規 C レベル関数を使う
  ように修正されました。 (Contributed by Fred L. Drake, Jr.)

* もうひとつ、主として Python デバッガ、開発ツールの実装者にとって興味
  深い低レベル API が追加されています。 "PyInterpreterState_Head()" と
  "PyInterpreterState_Next()" は呼び出し可能オブジェクトに、存在してい
  るインタプリタのオブジェクト全てを渡り歩かせます。
  "PyInterpreterState_ThreadHead()" と "PyThreadState_Next()" は与えら
  れたインタプリタについてのスレッド状態全てに渡るループを可能にしてい
  ます。 (Contributed by David Beazley.)

* ガーベージコレクタの C レベルインターフェイスが変更されています。こ
  れはガーベージコレクションをサポートする拡張型を書いたり、関数の利用
  誤りのデバッグをするのを簡単にします。多数の関数が少々これまでとは異
  なったセマンティクスを持つので、関数群がリネームされました。旧 API
  を使う拡張はこれまで通りコンパイルは出来ますが、ガーベージコレクショ
  ンには参加 *出来ません* 。このため 2.2 のためにはかなり高優先度で更
  新を検討すべきです。

  拡張モジュールを新 API でアップグレードするには、以下のステップを実
  施してください:

* "Py_TPFLAGS_GC()" を "PyTPFLAGS_HAVE_GC()" にリネームします。

* オブジェクトのアロケートには "PyObject_GC_New()" または
  "PyObject_GC_NewVar()" を使ってください。
     そしてオブジェクトのデアロケートには "PyObject_GC_Del()" を使って
     ください。

* "PyObject_GC_Init()" は "PyObject_GC_Track()" にリネームし、
     "PyObject_GC_Fini()" は "PyObject_GC_UnTrack()" にリネームしてく
     ださい。

* オブジェクトのサイズ計算をするのに "PyGC_HEAD_SIZE()" を使うのをやめ
  ます。

* "PyObject_AS_GC()" と "PyObject_FROM_GC()" 呼び出しを削除します。

* "PyArg_ParseTuple()" に新たな書式化シーケンス "et" が追加されました
  。 "et" はパラメータとエンコーディング名の両方を取りパラメータを与え
  られたエンコーディングで変換しますが、パラメータが Unicode である場
  合には変換し、8 ビット文字列である場合にはこれが既に望みのものである
  ことと仮定してそのままにします。このことは "es" 書式化文字が 8 ビッ
  ト文字列は Python デフォルトの ASCII エンコーディングであると仮定し
  て新たに与えられたエンコーディングで変換するのとは違っています。
  (Contributed by M.-A. Lemburg, and used for the MBCS support on
  Windows described in the following section.)

* A different argument parsing function, "PyArg_UnpackTuple()", has
  been added that's simpler and presumably faster.  Instead of
  specifying a format string, the caller simply gives the minimum and
  maximum number of arguments expected, and a set of pointers to
  "PyObject*" variables that will be filled in with argument values.

* メソッド定義テーブルでの新規フラグ "METH_NOARGS" と "METH_O" が利用
  可能です。これは引数なし、または単一の型の特定されない引数を取るメソ
  ッドの実装を単純化します。 "METH_VARARGS" を使って同じことをするより
  も、これらを使うと呼び出しがより効率的です。また C メソッドの記述に
  使う古い "METH_OLDARGS" スタイルは公式に非推奨となりました。

* 比較的新しい C ライブラリである "snprintf()" と "vsnprintf()" につい
  てのクロスプラットフォームな実装として、ラッパー関数
  "PyOS_snprintf()" と "PyOS_vsnprintf()" が追加されています。標準の
  "sprintf()" と "vsprintf()" とは対照的に、Python バージョンはバッフ
  ァオーバランから守るためにバッファの境界チェックを行います。
  (Contributed by M.-A. Lemburg.)

* "_PyTuple_Resize()" 関数の未使用パラメータを取り除いたので、今後は 3
  つではなく 2 つのパラメータを取ります。3 つ目の引数は一度も使われる
  ことはなかったため、Python 2.2 以前のコードからの移植時には単純に捨
  てることが出来ます。


その他の変更と修正
==================

いつものように、たくさんのほかの改善とバグフィックスがソースツリー全体
に渡って散らばっています。CVS 変更ログを検索すると、Python 2.1 から
2.2 にかけて適用されたパッチは 527、バグ修正は 683、2.2.1 で適用された
パッチは 139、バグ修正は 143、2.2.2 で適用されたパッチは 106、バグ修正
は 82。いずれも少なく見積もって、です。

ほかの、さらに特筆すべき変更のいくつかを挙げます:

* The code for the MacOS port for Python, maintained by Jack Jansen,
  is now kept in the main Python CVS tree, and many changes have been
  made to support MacOS X.

  The most significant change is the ability to build Python as a
  framework, enabled by supplying the "--enable-framework" option to
  the configure script when compiling Python.  According to Jack
  Jansen, "This installs a self-contained Python installation plus the
  OS X framework "glue" into "/Library/Frameworks/Python.framework"
  (or another location of choice). For now there is little immediate
  added benefit to this (actually, there is the disadvantage that you
  have to change your PATH to be able to find Python), but it is the
  basis for creating a full-blown Python application, porting the
  MacPython IDE, possibly using Python as a standard OSA scripting
  language and much more."

  Most of the MacPython toolbox modules, which interface to MacOS APIs
  such as windowing, QuickTime, scripting, etc. have been ported to OS
  X, but they've been left commented out in "setup.py".  People who
  want to experiment with these modules can uncomment them manually.

* キーワード引数を取らないビルトイン関数にそれを渡すと、メッセージ
  "*function* takes no keyword arguments" を伴う "TypeError" 例外を励
  起するようになりました。

* Python 2.1 で拡張モジュールとして追加された弱参照は、今では Python
  中核の一部です。これは新スタイルクラスの実装のために使われるからです
  。このため "weakref" モジュールにいた "ReferenceError" 例外をビルト
  イン例外に移動しました。

* Tim Peters による新しいスクリプト "Tools/scripts/cleanfuture.py" は
  、Python ソースコードから自動的に廃止された "__future__" 文を削除し
  ます。

* ビルトイン関数 "compile()" に *flags* 引数が追加され、これにより
  "__future__" ステートメントの振る舞いが、IDLE 内やほかの開発環境内に
  ある模擬的なシェル内で正しく準拠するようになりました。この変更は
  **PEP 264** に記述されています。 (Contributed by Michael Hudson.)

* Python 1.6 で導入された新ライセンスは GPL 互換ではありませんでした。
  2.2 ライセンスのためにいくつか小さな字句的修正によりこれをフィックス
  し、GPL プログラム内に Python を埋め込むことが再び合法になりました。
  Python そのものは GPL ではなく、かつても今後も BSD ライセンスに本質
  的に等価なものであることに注意してください。このライセンスの変更は
  Python 2.0.1 リリース、2.1.1 リリースにも適用されました。

* Windows において Unicode ファイル名がある場合に、Python はそれを
  Microsoft ファイル API を使うことで MBCS 文字列に変換するようになり
  ました。MBCS はそのファイル API によって明示的に使われるので、デフォ
  ルトのエンコーディングとして Python が ASCII を選択するのは苛立たし
  いことがわかりました。Unix においては "locale.nl_langinfo(CODESET)"
  が利用可能であればロケールの文字セットが使われます。 (Windows
  support was contributed by Mark Hammond with assistance from Marc-
  André Lemburg. Unix support was added by Martin von Löwis.)

* Windows でのラージファイルのサポートが有効になりました。
  (Contributed by Tim Peters.)

* "Tools/scripts/ftpmirror.py" スクリプトが、もしあれば、 ".netrc" フ
  ァイルを読むようになりました。 (Contributed by Mike Romberg.)

* "xrange()" 関数より返されるオブジェクトのいくつかの機能が非推奨とな
  り、それにアクセスすると警告が発せられます。これら機能は Python 2.3
  では削除されます。 "xrange" オブジェクトはスライス、シーケンスの積算
  、 "in" 演算子のサポートをすることによりシーケンス型を完全に装うよう
  に試みられましたが、これら機能が使われることは稀だったためにバギーで
  した。 "tolist()" メソッドと属性 "start", "stop", "step" も同様に非
  推奨になります。 C レベルでは "PyRange_New()" 関数の 4 つ目の引数
  "repeat" も非推奨になりました。

* 辞書実装に対するパッチの束がありました。ほとんどが、辞書にこっそりと
  そのハッシュ値を変更するオブジェクトを含んでいたり、それが含まれる辞
  書を変更する場合に潜在的にコアダンプしていたことに対する修正です。
  Michael Hudson がコアダンプするケースを見つけて python-dev に穏やか
  なリズムで報告している間に Tim Peters がバグをフィックスし、 Michael
  がまた別のケースを見つけ、ということを繰り返しました。

* On Windows, Python can now be compiled with Borland C thanks to a
  number of patches contributed by Stephen Hansen, though the result
  isn't fully functional yet.  (But this *is* progress...)

* Another Windows enhancement: Wise Solutions generously offered
  PythonLabs use of their InstallerMaster 8.1 system.  Earlier
  PythonLabs Windows installers used Wise 5.0a, which was beginning to
  show its age.  (Packaged up by Tim Peters.)

* ファイル名が ".pyw" で終わるものが Windows でインポート出来るように
  なりました。 ".pyw" は Windows のみのものであり、スクリプトが
  PYTHON.EXE ではなく PYTHONW.EXE を使って実行されることを示すのに使わ
  れます。これは出力のために DOS コンソールがポップアップしてしまうの
  を避けるのに使われます。このパッチはそのようなスクリプトを、それがモ
  ジュールとしても利用可能であるケースでインポート出来るようにします。
  (Implemented by David Bolen.)

* Python が C の "dlopen()" 関数を拡張モジュールのロードに用いるプラッ
  トフォームにおいて、 "dlopen()" で使われるフラグを
  "sys.getdlopenflags()" 関数と "sys.setdlopenflags()" 関数でセット出
  来るようになりました。 (Contributed by Bram Stolk.)

* 組み込み関数 "pow()" はもはや浮動小数点数の際の 3 番目の引数をサポー
  トしません。 "pow(x, y, z)" は "(x**y) % z" を返しますが、浮動小数点
  の場合はこれは決して役には立ちません。最終結果はプラットフォーム依存
  で予測不可能なものになります。 "pow(2.0, 8.0, 7.0)" のような呼び出し
  は、 "TypeError" 例外を発生させるようにしました。


謝辞
====

著者は提案の申し出や修正、様々なこの記事の草稿の助けをしてくれた以下の
人々に感謝します:  Fred Bremmer, Keith Briggs, Andrew Dalke, Fred L.
Drake, Jr., Carel Fellinger, David Goodger, Mark Hammond, Stephen
Hansen, Michael Hudson, Jack Jansen, Marc-André Lemburg, Martin von
Löwis, Fredrik Lundh, Michael McLay, Nick Mathewson, Paul Moore,
Gustavo Niemeyer, Don O'Donnell, Joonas Paalasma, Tim Peters, Jens
Quade, Tom Reinhardt, Neil Schemenauer, Guido van Rossum, Greg Ward,
Edward Welbourne.
