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 モデルについてのものです。変更は後方互換であるはずなので、あなたのコードは変更なしで動きそうです。ですがその変更は、いくつかの素晴らしい能力を発揮させます。この、本記事中において最も長くて複雑なセクションについて始める前に、変更の概要を提供し、いくつかの所感を提示しておこうと思います。

ずっと前に、私は Python の設計上の欠点を列挙した Web ページを書きました。特に重大な欠点の一つは、C で実装された Python の型のサブクラスを作れないことでした。とりわけ組み込み型のサブクラスを作れないため、例えばリストに便利なメソッドを一つ追加するだけでも、リストを継承するという方法は使えません。 UserList モジュールには、リストのすべてのメソッドを備え、さらに継承もできるクラスがありますが、通常の Python のリストを要求し、UserList のインスタンスを受け付けない C コードも数多くあります。

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

あなたはリストのような組み込み型をサブクラス化出来ます。整数でさえ出来ます。そしてあなたのサブクラスは、元の型を要求している全ての場所で動作します。
以前より使えたインスタンスメソッド加え、静的メソッド、クラスメソッドを今や定義出来ます。
プロパティ と呼ばれる新しい仕組みにより、インスタンス属性へのアクセスや設定の際に、自動的にメソッドを呼び出すことも可能です。 __getattr__() を使っていた多くの箇所はプロパティを使う形に書き直せ、コードが簡単になり高速化します。さらに、属性にも 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):
        ...
    ...

したがって、基底クラスを持たない class 文は、Python 2.2 では常に旧スタイルクラスになります。 (実際には __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 のバージョンに委ねられています。

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

from eiffel import eiffelmethod

class C(object):
    def f(self, arg1, arg2):
        # 実際の関数
        ...
    def pre_f(self):
        # 事前条件を確認
        ...
    def post_f(self):
        # 事後条件を確認
        ...

    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 ではこのアルゴリズムはさらに変更されて、ほとんどのケースで同じ結果となり、本当に複雑な継承グラフの場合にもっと有用な結果となりました)。

従来の検索規則に従ってすべての基底クラスを列挙し、同じクラスに何度も到達した場合はその都度リストに含めます。上の例では、列挙されるクラスは [D, B, A, C, A] です。
リストを調べてクラスの重複を見つけます。重複があれば、最後のものを一つだけ残してほかを削除します。上の例では、重複を取り除くと [D, B, C, A] になります。

この規則に従えば、D.save() を参照すると C.save() が返され、求めていた動作になります。これは Common Lisp と同じ検索規則です。新しい組み込み関数 super() を使えば、Python のアルゴリズムを自分で実装し直さずにクラスのスーパークラスにアクセスできます。最もよく使う形式は super(class, obj) で、これは束縛されたスーパークラスのオブジェクトを返します (実際のクラスオブジェクトではありません)。この形式はメソッド内からスーパークラスのメソッドを呼び出す際に使います。例えば D の save() メソッドは次のようになります。

class D (B,C):
    def save (self):
        # スーパークラスの .save() を呼び出す
        super(D, self).save()
        # ここで D 固有の情報を保存
        ...

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

属性アクセス¶

高度な Python のクラスのかなり多くが、__getattr__() で属性アクセスのフックを定義しています。特によくあるのは利便性のためで、obj.parent のような属性アクセスを obj.get_parent のようなメソッド呼び出しへ自動的に対応付け、コードを読みやすくしています。 Python 2.2 では、属性アクセスを制御する新しい方法がいくつか加わりました。

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

New-style classes also support a new method, __getattribute__(attr_name). The difference between the two methods is that __getattribute__() is always called whenever any attribute is accessed, while the old __getattr__() is only called if foo isn't found in the instance's dictionary.

ただし、属性の参照を捕捉するには、Python 2.2 でサポートされた プロパティ を使う方が簡単な場合が多いでしょう。 __getattr__() メソッドを書くのは複雑です。再帰を避けるためにメソッドの内部では通常の属性アクセスを使えず、代わりに __dict__ の内容を操作しなければならないからです。また Python が __repr__() や __coerce__() などの別のメソッドを探すときにも __getattr__() メソッドが呼ばれるので、そのことを考慮して書く必要があります。さらに、属性にアクセスするたびに関数を呼び出すと、性能が大きく低下します。

property は、属性を取得、設定、削除する 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 ...

    # プロパティを定義します。「この属性を削除する」
    # メソッドは None として定義しているので、
    # この属性は削除できません。
    size = property(get_size, set_size,
                    None,
                    "このインスタンスの記憶域のサイズ")

これは確かに、__getattr__() と __setattr__() の両メソッドで size 属性だけを特別に扱い、ほかの属性はすべてインスタンスの __dict__ から取得するように書くよりも明快で、記述も簡単です。関数呼び出しが必要になるのも 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 になっていることに注目してください。

PEP 234: イテレータ¶

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

Python 2.1 以前では、for item in obj を動作させる一般的な方法は、次のような __getitem__() メソッドを定義することでした。

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

__getitem__() の本来の用途は、obj[5] と書いて 6 番目の要素を取得できるよう、オブジェクトのインデックス操作を定義することです。これを for ループに対応するためだけに使うと、少し誤解を招きます。ループで走査できるようにしたいファイル風オブジェクトを考えてみてください。そのクラスはおそらく、index が毎回 1 ずつ増える一連の __getitem__() 呼び出しを想定しているので、index パラメーターに実質的な意味はありません。つまり __getitem__() メソッドがあっても、file[5] で 6 番目の要素にランダムアクセスできるとは限りませんが、本来はできるはずなのです。

Python 2.2 では反復処理を独立して実装でき、__getitem__() メソッドを本当にランダムアクセスに対応するクラスだけに限定できます。イテレータの基本的な考え方は単純です。新しい組み込み関数 iter(obj) または iter(C, sentinel) でイテレータを取得します。 iter(obj) はオブジェクト obj のイテレータを返します。一方 iter(C, sentinel) は、呼び出し可能オブジェクト C を繰り返し呼び出し、終了を示す sentinel が返されたら反復を終えるイテレータを返します。

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] は引き続き動作します。 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

これはデフォルトの動作にすぎません。キー、値、キーと値の組を反復処理したい場合は、iterkeys()、itervalues()、iteritems() メソッドを明示的に呼び出して、対応するイテレーターを取得できます。関連する小さな変更として、in 演算子が辞書でも使えるようになり、key in dict は dict.has_key(key) と同じ意味になりました。

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

for line in file:
    # 各行について処理する
    ...

イテレータは前進しか出来ないことに注意してください; 前の要素を取り出す手段もなければ、イテレータをリセットしたりコピーしたりといったことも出来ません。イテレータオブジェクトにそのような追加の能力を持たせることは出来ますが、イテレータプロトコルが規定するのは 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://www2.cs.arizona.edu/icon/) から着想しています。Icon ではジェネレータが言語の中枢になっています。Icon では、あらゆる式と関数がジェネレータのように振舞います。 https://www2.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**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 構造体にスロットがあり、拡張型でこれらの演算子を定義できます。
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 サポートを無効にすることも出来ます。)

When built to use UCS-4 (a "wide Python"), the interpreter can natively handle Unicode characters from U+000000 to U+110000, so the range of legal values for the unichr() function is expanded accordingly. Using an interpreter compiled to use UCS-2 (a "narrow Python"), values greater than 65535 will still cause unichr() to raise a ValueError exception. This is all described in PEP 261, "Support for 'wide' Unicode characters"; consult it for further details.

もう一つの変更は簡単に説明できます。 Unicode 文字列は導入当初から、UTF-8 や Latin-1 など指定したエンコーディングに変換する encode() メソッドをサポートしていました。 2.2 では、これと対になる decode([*encoding*]) メソッドが 8 ビット文字列に追加されました (Unicode 文字列には追加されていません)。 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 に変換するために、クラスで __str__() に相当する __unicode__() メソッドを定義できます。

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):
    "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():
    # 次の行は構文エラー
    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 Network から RSS チャンネルの一覧を取得し、一つのチャンネルの最新の見出しを列挙します。
```
import xmlrpclib
s = xmlrpclib.Server(
      'http://www.oreillynet.com/meerkat/xml-rpc/server.php')
channels = s.meerkat.getChannels()
# channels は次のような辞書のリスト:
# [{'id': 4, 'title': 'Freshmeat Daily News'}
#  {'id': 190, 'title': '32Bits Online'},
#  {'id': 4549, 'title': '3DGamers'}, ... ]

# 一つのチャンネルの項目を取得
items = s.meerkat.getItems( {'channel': 4} )

# items も次のような辞書のリスト:
# [{'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.)
Several functions that originally returned lengthy tuples now return pseudo-sequences that still behave like tuples but also have mnemonic attributes such as st_mtime or tm_year. The enhanced functions include stat(), fstat(), statvfs(), and fstatvfs() in the os module, and localtime(), gmtime(), and strptime() in the time module.

例えば旧式のタプルでファイルサイズを得るには 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.)
C の long long 型をサポートするプラットフォーム向けに、64 ビット整数を扱う 2 つの書式文字が struct モジュールに追加されました。 q は符号付き、Q は符号なしの 64 ビット整数を表します。値は Python の長整数型として返されます。 (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 の保守担当は Fredrik Lundh です。BIGCHARSET パッチは 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.)
rfc822 モジュールのメールアドレスの解析が、RFC 822 を更新した RFC 2822 に準拠するようになりました。 (モジュール名を rfc2822 に変更する予定は ありません。) 電子メールメッセージを解析・生成する新しいパッケージ email も追加されました。 (Barry Warsaw による Mailman の開発から生まれた貢献です。)
difflib モジュールに、2 つのテキスト行のシーケンスの間の変更点 (「差分」) を読みやすいリストにする、新しい Differ クラスが加わりました。また、ジェネレータ関数 ndiff() と restore() も加わりました。前者は 2 つのシーケンスから差分を返し、後者は差分から元のシーケンスの一方を返します。 (Tim Peters の ndiff.py をもとに David Goodger が主要な作業を行い、その後 Tim Peters がジェネレータ化しました。)
string モジュールに、新しい定数 ascii_letters、ascii_lowercase、ascii_uppercase が加わりました。標準ライブラリのいくつかのモジュールは、string.letters を A-Za-z の範囲という意味で使っていました。しかし string.letters は現在のロケールが定義する有効な文字の集合に応じて変わるため、ロケールの使用時にはその想定は誤りです。これらのバグのあるモジュールはすべて、代わりに ascii_letters を使うよう修正されました。 (報告者は不明、修正は Fred L. Drake, Jr. によるものです。)
mimetypes モジュールに、解析するファイル名のリストを受け取る MimeTypes クラスが追加され、別の MIME 型データベースを使いやすくなりました。 (Fred L. Drake, Jr. が貢献しました。)
threading モジュールに Timer クラスが追加され、後の時刻に処理を実行するようスケジュールできるようになりました。 (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() を使うと、指定したインタープリタのすべてのスレッド状態をたどれます。 (David Beazley が貢献しました。)
ガーベージコレクタの C レベルインターフェイスが変更されています。これはガーベージコレクションをサポートする拡張型を書いたり、関数の利用誤りのデバッグをするのを簡単にします。多数の関数が少々これまでとは異なったセマンティクスを持つので、関数群がリネームされました。旧 API を使う拡張はこれまで通りコンパイルは出来ますが、ガーベージコレクションには参加 出来ません 。このため 2.2 のためにはかなり高優先度で更新を検討すべきです。

拡張モジュールを新 API でアップグレードするには、以下のステップを実施してください:
Py_TPFLAGS_GC を Py_TPFLAGS_HAVE_GC に改名します。
Use PyObject_GC_New() or PyObject_GC_NewVar() to allocate objects, and PyObject_GC_Del() to deallocate them.
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.)
より単純で、おそらく高速な別の引数解析関数 PyArg_UnpackTuple() が追加されました。呼び出し側は書式文字列の代わりに、想定する引数の最小数と最大数、および引数の値を格納する PyObject* 変数へのポインターを渡すだけです。
引数を取らないメソッドや、型を限定しない引数を一つ取るメソッドの実装を簡単にするため、メソッド定義テーブルで 2 つの新しいフラグ METH_NOARGS と METH_O を使えるようになりました。このようなメソッドの呼び出しは、同等の処理を METH_VARARGS で実装したメソッドの呼び出しより効率的です。また、C のメソッドを記述する旧来の METH_OLDARGS 形式が正式に非推奨となりました。
比較的新しい C ライブラリの API snprintf() と vsnprintf() をプラットフォームによらず使えるようにするため、新しいラッパー関数 PyOS_snprintf() と PyOS_vsnprintf() が追加されました。標準の sprintf() 関数や vsprintf() 関数と異なり、Python 版は使用するバッファの境界を確認してバッファオーバーランを防ぎます。 (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。いずれも少なく見積もって、です。

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

Jack Jansen が保守する Python の MacOS 移植版のコードは、メインの Python CVS ツリーで管理されるようになり、MacOS X をサポートするための多くの変更が行われました。

最も重要な変更は、Python をフレームワークとしてビルドできるようになったことです。 Python のコンパイル時に configure スクリプトへ --enable-framework オプションを渡すと有効になります。 Jack Jansen は次のように説明しています。「これにより、自己完結した Python 環境と OS X フレームワークとの連携部分が /Library/Frameworks/Python.framework (または任意の別の場所) にインストールされます。今のところ、これ自体による直接的な利点はほとんどありません (実際には、Python を見つけられるように PATH を変更する必要があるという欠点があります)。しかしこれは、本格的な Python アプリケーションの作成、MacPython IDE の移植、Python を標準の OSA スクリプト言語として使う可能性など、さまざまなことの基礎となります。」

ウィンドウ、QuickTime、スクリプトなどの MacOS API に接続する MacPython の toolbox モジュールの大部分は OS X に移植されましたが、setup.py ではコメントアウトされたままです。これらのモジュールを試したい場合は、自分でコメントを解除できます。
キーワード引数を取らないビルトイン関数にそれを渡すと、メッセージ "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 がまた別のケースを見つけ、ということを繰り返しました。
Stephen Hansen の多数のパッチにより、Windows では Borland C で Python をコンパイルできるようになりました。ただし、まだ完全には動作しません。 (それでも、これは進歩です。)
Windows 向けのもう一つの改善として、Wise Solutions が PythonLabs に InstallerMaster 8.1 システムの使用を快く提供しました。従来の PythonLabs の Windows インストーラーは、古さが目立ち始めていた Wise 5.0a を使っていました。 (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.

What's New in Python 2.2¶

はじめに¶

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

旧と新クラス¶

デスクリプタ¶

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

属性アクセス¶

PEP 234: イテレータ¶

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

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

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

Unicode の変更¶

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

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

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

その他の変更と修正¶

謝辞¶

目次

前のトピックへ

次のトピックへ

このページ

What's New in Python 2.2¶

はじめに¶

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

旧と新クラス¶

デスクリプタ¶

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

属性アクセス¶

関連リンク¶

PEP 234: イテレータ¶

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

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

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

Unicode の変更¶

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

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

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

その他の変更と修正¶

謝辞¶