3119 抽象基底クラスの導入¶

著者について¶

Talin が以下の提案理由 [1] と ABC 対インタフェースの節の大半を書きました。 そのことによって彼が共著者に名を連ねることになりました。 その他の部分における一人称「私」は第一著者を指します。

isinstance() および issubclass() の多重定義¶

この PEP と付随する PEP 3141 の発展の途上、私たちは繰り返し数多くの細粒度の ABC と少数の粗粒度の ABC どちらの方向で標準化するか選択に直面しました。 例えば、あるとき、PEP 3141 が以下の基底クラスの積み重なりを複素数のために導入しました: MonoidUnderPlus, AdditiveGroup, Ring, Field, Complex (それぞれ一つ前のものから派生します)。 その議論の中でさらに幾つかの代数的範疇が排除されました: Algebraic, Transcendental および IntegralDomain, PrincipalIdealDomain。 この PEP の以前のバージョンでは、以下のようなクラスのユースケースをそれぞれ考えました: Set, ComposableSet, MutableSet, HashableSet, MutableComposableSet, HashableComposableSet。

私たちのジレンマは、ABC の数は少ない方が良いと思っていても、 もっと細かい ABC が必要なユーザーはどうしたらいいのか、ということでした。 考えてみて下さい。 ある数学者が彼自身の超越数(Transcendental)を定義したかったとして、 しかも float や int も Transcendental として考えたい、 というときの苦境を。 PEP 3141 は当初 float.__bases__ をこうした目的のためにパッチすることを提案していましたが、 組み込み型を変更不可能に保つべきいくつもの理由があります (一つ挙げておくと、float は同じアドレス空間で実行される全ての Python (mod_python [16] のように) で共有されています)。

もう一つの例として総称的関数(generic function) (PEP 3124) を全ての append() メソッドを持つシーケンスに対して定義したい人を取り上げましょう。 Sequence ABC は(以下を参照) append() メソッドについては何も約束しません。 一方で MutableSequence は append() 以外にも多くの変更用メソッドを要求します。

これらの、そして同様な、ジレンマを解くために、次の節では ABC と共に用いるメタクラスを提案します。 このメタクラスは ABC を「仮想基底クラス」(C++ の概念とは異なりますが) を任意のクラス(他の ABC も含めて)に付け加えることができるようにするものです。 こうすることで標準ライブラリに Sequence, MutableSequence といった ABC を定義してこれらを組み込み型の basestring, tuple, list などの仮想基底クラスに追加することができ、以下の条件は全て真になります:

isinstance([], Sequence)
issubclass(list, Sequence)
issubclass(list, MutableSequence)
isinstance((), Sequence)
not issubclass(tuple, MutableSequence)
isinstance("", Sequence)
issubclass(bytearray, MutableSequence)

ここで提案している第一義のメカニズムは組み込み関数 isinstance() および issubclass() の多重定義(オーバーロード)ができるようにするものです。 多重定義は以下のようにして機能します: 呼び出し isinstance(x, C) は最初に C.__instancecheck__ が存在するかチェックし、存在すれば通常の実装に代わり、 C.__instancecheck__(x) を呼び出します。 同様に、呼び出し issubclass(D, C) は最初に C.__subclasscheck__ の存在をチェックし、存在すれば通常の実装の代わりに、 C.__subclasscheck__(D) を呼び出します。

気付いたと思いますが魔法の名前は __isinstance__ や __issubclass__ ではありません。 どうしてかというと、引数が逆順になるので、特に issubclass() を多重定義しようとするときに、混乱することを恐れたのです。

このメカニズムのプロトタイプ実装が [12] にあります。

では(極単純な) __instancecheck__ と __subclasscheck__ の実装 がある例を見ましょう:

class ABCMeta(type):

    def __instancecheck__(cls, inst):
        """Implement isinstance(inst, cls)."""
        return any(cls.__subclasscheck__(c)
                   for c in {type(inst), inst.__class__})

    def __subclasscheck__(cls, sub):
        """Implement issubclass(sub, cls)."""
        candidates = cls.__dict__.get("__subclass__", set()) | {cls}
        return any(c in candidates for c in sub.mro())

class Sequence(metaclass=ABCMeta):
    __subclass__ = {list, tuple}

assert issubclass(list, Sequence)
assert issubclass(tuple, Sequence)

class AppendableSequence(Sequence):
    __subclass__ = {list}

assert issubclass(list, AppendableSequence)
assert isinstance([], AppendableSequence)

assert not issubclass(tuple, AppendableSequence)
assert not isinstance((), AppendableSequence)

次節では目一杯盛り込んだ実装をお目に掛けましょう。

abc モジュール: ABC サポートフレームワーク¶

新しい標準ライブラリモジュール abc は Python だけで書かれており、 ABC サポートフレームワークとしての役目を果たします。 そこではメタクラス ABCMeta が定義され、 デコレータ @abstractmethod および @abstractproperty も定義されます。 サンプル実装が [13] にあります。

ABCMeta クラスは __instancecheck__ および __subclasscheck__ を上書き(オーバーライド)し、 register メソッドを定義します。 register メソッドは引数を一つ取り、それはクラスです。 ひとたび B.register(C) を呼び出すと、以降 issubclass(C, B) は B.__subclasscheck__(C) が True を返すと True を返すようになります。 同様に isinstance(x, B) は issubclass(x.__class__, B) or issubclass(type(x), B) と等価です。 (type(x) と x.__class__ が異なるクラスであることはたとえば x がプロキシーオブジェクトのときにありえます)

これらのメソッドはメタクラスが ABCMeta (から派生した) クラスに対して呼び出されることを想定しています。 たとえば:

from abc import ABCMeta

class MyABC(metaclass=ABCMeta):
    pass

MyABC.register(tuple)

assert issubclass(tuple, MyABC)
assert isinstance((), MyABC)

最後の二つの assert は次の二つと等価です:

assert MyABC.__subclasscheck__(tuple)
assert MyABC.__instancecheck__(())

もちろん、MyABC から直接派生することもできます:

class MyClass(MyABC):
    pass

assert issubclass(MyClass, MyABC)
assert isinstance(MyClass(), MyABC)

そしてもちろん、タプルは MyClass ではありません:

assert not issubclass(tuple, MyClass)
assert not isinstance((), MyClass)

他のクラスを MyClass のサブクラスとして登録することもできます:

MyClass.register(list)

assert issubclass(list, MyClass)
assert issubclass(list, MyABC)

他の ABC を登録することもできます:

class AnotherClass(metaclass=ABCMeta):
    pass

AnotherClass.register(basestring)

MyClass.register(AnotherClass)

assert isinstance(str, MyABC)

最後の assert では次のようなクラスの親子関係を追いかける必要があります:

MyABC -> MyClass (using regular subclassing)
MyClass -> AnotherClass (using registration)
AnotherClass -> basestring (using registration)
basestring -> str (using regular subclassing)

abc モジュールは新しいデコレータ @abstractmethod も定義しており、抽象メソッドの宣言に使います。 クラスにこのデコレータで宣言されたメソッドでまだ上書きしていないものがあるとインスタンス化できません。 こうしたメソッドをサブクラスの上書きメソッドから (super を使ったり直接呼び出したりして) 呼び出すことができます。 例です:

from abc import ABCMeta, abstractmethod

class A(metaclass=ABCMeta):
    @abstractmethod
    def foo(self): pass

A()  # raises TypeError

class B(A):
    pass

B()  # raises TypeError

class C(A):
    def foo(self): print(42)

C()  # works

注意: @abstractmethod デコレータはクラス定義の内部で使わなければならず、 しかもそのクラスのメタクラスは ABCMeta (から派生したメタクラス) でなければなりません。 動的に抽象メソッドをクラスに付け加えたり、 メソッドやクラスが抽象かどうかの状態を生成後に書き換えたり、 といった試みはサポートされません。 @abstractmethod が効果を持つのは通常の継承で派生したクラスだけで、 register() で登録された「仮想サブクラス」には影響を及ぼしません。

実装: @abstractmethod デコレータは関数の属性 __isabstractmethod__ を True にします。 ABCMeta.__new__ メソッドは型属性 __abstractmethods__ を __isabstractmethod__ 属性が真であるメソッド名の集合として求めます。 もう少し詳細に見ると、基底クラスたちの __abstractmethods__ を合算し、 新しいクラスの辞書の中で __isabstractmethod__ が真であるメソッドの名前を加え、 逆にそれが真でないメソッドの名前を取り除きます。 この結果得られる集合 __abstractmethods__ が空でない場合、 そのクラスは抽象クラスであると判断され、 そのクラスをインスタンス化しようとすると TypeError が送出されます。 (これが CPython で実装される際には、内部フラグ Py_TPFLAGS_ABSTRACT を使ったチェックの高速化が図られるでしょう [6])

議論: Java の抽象メソッドや C++ の純粋抽象メソッドとは異なり、 ここで定義される抽象メソッドには実装があってもかまいません。 この実装は super メカニズムを通してメソッドを上書きしたクラスから呼び出され得ます。 こうしておくと協調的多重継承を用いたフレームワークの super 呼び出しの終着点として便利です [7], [8] 。

第二のデコレータ @abstractproperty は抽象データ属性を定義するためのものです。 実装は組み込みの property クラスに __isabstractmethod__ 属性を加えたサブクラスです:

class abstractproperty(property):
    __isabstractmethod__ = True

二つの使い方があります:

class C(metaclass=ABCMeta):

    # A read-only property:

    @abstractproperty
    def readonly(self):
        return self.__x

    # A read-write property (cannot use decorator syntax):

    def getx(self):
        return self.__x
    def setx(self, value):
        self.__x = value
    x = abstractproperty(getx, setx)

抽象メソッドと同様に、抽象プロパティ(デコレータ構文をつかうか長い形式で宣言されたもの)を継承したサブクラスは、具象プロパティで抽象プロパティを上書きしない限りインスタンス化できません。

コンテナとイテレータのための ABC¶

collections モジュールは集合、マッピング、シーケンスおよびいくつかの補助的な型(イテレータや辞書のビュー)を扱うのに必要にして十分な ABC を定義します。 全ての ABC は上述の ABCMeta をメタクラスに使います。

これらの ABC は抽象メソッドを提供し、それらは技術的には正当ですが実際には何の役にも立ちません。 たとえば __hash__ は 0 を返し、 __iter__ は空のイテレータを返します。 一般に、抽象メソッドは型が決める空のコンテナの振る舞いを表します。

いくつかの ABC は具象(つまり非抽象)メソッドも提供します。 たとえば、 Iterator クラスには __iter__ メソッドがあり、 それ自身を返します。 これはイテレータの重要な不変条件です (この振る舞いは Python 2 では各イテレータクラスが実装しなければなりませんでした)。 これらの ABC は”ミックスイン(mix-in)”クラスと考えることができます。

この PEP で定義するどの ABC も __init__, __new__, __str__, __repr__ を上書きしません。 コンストラクタの標準的なシグニチャを決めることは、 たとえばパトリシア木や gdbm ファイルの、 自作コンテナ型に対する余計な制約です。 特定の文字列表現をコレクションに対して定義する仕事は、 同様に個別の実装者に任せるようにしてあります。

注意: 順序演算 (__lt__, __le__, __ge__, __gt__) に関する ABC はありません。 これらを基底クラス(抽象かどうかに関わらず)で定義することは、 第二引数の型に何を受け付けるかという問題を引き起こします。 たとえば、クラス Ordering で __lt__ を定義したとすると、 どんな Ordering のインスタンス x と y に対しても x < y が定義されることになります (半順序だけ定義するにしても)。 しかし、これは無理です: もし list と str が共に Ordering から派生したとすると、 [1, 2] < (1, 2) が定義されなければなりません (多分 False を返すのでしょう)。 一方で、実際には (Python 3000 では!) そうした「混在モードの比較」演算は禁止すると明文化され TypeError を送出します。 詳しくは PEP 3100 および [14] を参照して下さい。 (これは同じ型の引数をもう一つ取る演算における一般的な問題の一例です。)

class Sized(metaclass=ABCMeta):
    @abstractmethod
    def __hash__(self):
        return 0
    @classmethod
    def __instancecheck__(cls, x):
        return hasattr(x, "__len__")
    @classmethod
    def __subclasscheck__(cls, C):
        return hasattr(C, "__bases__") and hasattr(C, "__len__")

文字列¶

Python 3000 には少なくとも2種類の文字列型が存在することになりそうです: バイト列 (bytes) は MutableSequence から、 (ユニコード)文字列 (str) は Sequence と Hashable から、 それぞれ派生します。

未解決問題: これらの基底インタフェースを定義して、代替実装やサブクラスがどの種類のものかを知ることができるようにしてください。 この問題は新しい PEP (複数かもしれません) の主題になるでしょう。 (bytes 型については PEP 358 も一緒に考えなければなりません)。

ABCs vs. ダックタイピング¶

ABC の導入によってダックタイピングは滅びるのでしょうか? 多分そうはならないでしょう。 Python は __getitem__ メソッドを定義する時に BasicMapping や Sequence から派生するようには要求しませんし、 x[y] の文法も x にどちらかの ABC のインスタンスであることを要求しません。 依然として write メソッドさえ具えている「ファイル風」オブジェクトであれば、 sys.stdout に割り当てることができます。

もちろん、ユーザーが適切な基底クラスを使う方向に進むようにニンジンをぶらさげることはあるかもしれません。 たとえば特定の機能性に対するデフォルト実装であったり、 マッピングとシーケンスを見分ける能力を向上させることであったり。 しかしムチが飛ぶわけではありません。 hasattr(x, "__len__") で十分ということであれば、そのままで結構。 ABC は Python 2 に良い解決策が無かった、たとえばマッピングとシーケンスを見分けるといった問題を解決したいというものなのです。

ABCs vs. 総称関数¶

ABC は総称関数 (generic function, GF) と互換性があります。 たとえば私自身の総称関数の実装 [4] は引数のクラス(型)をディスパッチのキーとして使い、 派生クラスが基底クラスを再定義することを許します。 ABC は (Python の視点からは) ごく普通のクラスで、 ABC を GF のデフォルト実装に使うのはとても自然です。 たとえば、私は多重定義された pretyprint 関数を持っていますが、 集合のプリティプリントの定義を以下のようにしておいて無理はないでしょう:

@prettyprint.register(Set)
def pp_set(s):
    return "{" + ... + "}"  # 詳細は練習問題です

そして Set の特定のサブクラスに対する実装を追加するのは簡単です。

その他、 RuleDispatch や Phillip Eby の PEAK にある GF 実装 [5] とも一緒に使って問題ないと私は信じています。

もちろん、GF 支持者は GF が (そして具象的クラスつまり実装されたクラス) が欲しいと主張することでしょう。 しかし彼らとて継承の有用性を否定はしないでしょう。 この PEP で提案されている ABC をオプションの実装基底クラスと考えても構わないでしょう。 ユーザーが定義する全てのマッピングが BasicMapping から派生しなければならないというような要求はありません。

ABC vs. インタフェース¶

ABC は本来的にインタフェースと非互換的というわけではありませんが、 多くの共通部分があります。 ここでは、インタフェース支持者になぜインタフェースの方が優れているかという説明は任せることにします。 思うに、進めてきた作業の多く、例えば「マッピング性」の様々な側面の定義および命名規則は、ABC の代わりにインタフェースを使う提案に簡単に適用できそうです。

この文脈で「インタフェース」というのはクラスに付加される追加のメタデータ要素の提案で、これらのメタデータは通常のクラス階層とは別物です。 一方でこれらによってある種の継承テストができるようになるものです。

そうしたメタデータは、少なくとも幾つかの提案では、 アプリケーションごとに容易に変更できるようにデザインされ、 アプリケーション作者がオブジェクトの普通の分類を再定義することが許されます。

このクラスに変更可能なメタデータを付加するというアイディアの欠点は、 クラスというものは共有される状態であり、 それを変更してしまうと意図がずれてしまうかもしれないことです。 付け加えて、オブジェクトの分類を再定義するニーズは総称関数によってより簡潔に実現できます。 一番単純な場合、「カテゴリーへの所属」総称関数を定義して、 それが基底実装では単純に False を返し関心のあるクラスに対しては True を返すように再定義したものを提供することができます。