Danksagungen

Talin schrieb die unten stehende Begründung [1] sowie den größten Teil des Abschnitts über ABCs vs. Schnittstellen. Allein dafür verdient er eine Co-Autorschaft. Der Rest des PEP verwendet „Ich“ in Bezug auf den Erstautor.

Überladen von isinstance() und issubclass()

Während der Entwicklung dieses PEP und seines Begleitdokuments PEP 3141 standen wir wiederholt vor der Wahl, entweder mehr, feingranulare ABCs oder weniger, grob granulare ABCs zu standardisieren. Zum Beispiel führte PEP 3141 zu einem Zeitpunkt die folgende Hierarchie von Basisklassen für komplexe Zahlen ein: MonoidUnderPlus, AdditiveGroup, Ring, Field, Complex (jeweils abgeleitet von der vorherigen). Und die Diskussion erwähnte mehrere andere algebraische Kategorisierungen, die weggelassen wurden: Algebraic, Transcendental und IntegralDomain, und PrincipalIdealDomain. In früheren Versionen des aktuellen PEP haben wir die Anwendungsfälle für separate Klassen wie Set, ComposableSet, MutableSet, HashableSet, MutableComposableSet, HashableComposableSet berücksichtigt.

Das Dilemma hier ist, dass wir lieber weniger ABCs hätten, aber was soll ein Benutzer tun, der eine weniger verfeinerte ABC benötigt? Betrachten Sie z. B. das Los eines Mathematikers, der seine eigene Art von Transzendentalzahlen definieren möchte, aber auch möchte, dass float und int als Transzendental betrachtet werden. PEP 3141 schlug ursprünglich vor, `float.__bases__` für diesen Zweck zu patchen, aber es gibt einige gute Gründe, die eingebauten Typen unveränderlich zu halten (zum einen werden sie von allen Python-Interpretern im selben Adressraum gemeinsam genutzt, wie sie von mod_python verwendet werden [16]).

Ein weiteres Beispiel wäre jemand, der eine generische Funktion (PEP 3124) für jede Sequenz definieren möchte, die eine `append()`-Methode hat. Die `Sequence`-ABC (siehe unten) garantiert die `append()`-Methode nicht, während `MutableSequence` nicht nur `append()`, sondern auch verschiedene andere mutierende Methoden erfordert.

Um diese und ähnliche Dilemmata zu lösen, wird im nächsten Abschnitt eine Metaklasse für die Verwendung mit ABCs vorgeschlagen, die es uns ermöglicht, eine ABC als „virtuelle Basisklasse“ (nicht dasselbe Konzept wie in C++) zu jeder Klasse hinzuzufügen, auch zu einer anderen ABC. Dies ermöglicht es der Standardbibliothek, die ABCs `Sequence` und `MutableSequence` zu definieren und diese als virtuelle Basisklassen für integrierte Typen wie `basestring`, `tuple` und `list` zu registrieren, sodass zum Beispiel die folgenden Bedingungen alle wahr sind

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

Der primär vorgeschlagene Mechanismus ist, die integrierten Funktionen isinstance() und issubclass() überladen zu können. Das Überladen funktioniert wie folgt: Der Aufruf isinstance(x, C) prüft zuerst, ob C.__instancecheck__ existiert, und wenn ja, ruft C.__instancecheck__(x) anstelle seiner normalen Implementierung auf. Ebenso prüft der Aufruf issubclass(D, C) zuerst, ob C.__subclasscheck__ existiert, und wenn ja, ruft C.__subclasscheck__(D) anstelle seiner normalen Implementierung auf.

Beachten Sie, dass die magischen Namen nicht __isinstance__ und __issubclass__ sind; dies liegt daran, dass die Umkehrung der Argumente zu Verwirrung führen könnte, insbesondere für den issubclass()-Überlader.

Eine prototypische Implementierung davon ist in [12] gegeben.

Hier ist ein Beispiel mit (naiverweise einfachen) Implementierungen von __instancecheck__ und __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)

Der nächste Abschnitt schlägt eine vollwertige Implementierung vor.

Das Modul abc: Ein ABC-Unterstützungsframework

Das neue Standardbibliotheksmodul abc, geschrieben in reinem Python, dient als Framework zur Unterstützung von ABCs. Es definiert eine Metaklasse ABCMeta und die Dekoratoren @abstractmethod und @abstractproperty. Eine Beispielimplementierung wird von [13] bereitgestellt.

Die Klasse ABCMeta überschreibt __instancecheck__ und __subclasscheck__ und definiert eine Methode register. Die Methode register nimmt ein Argument entgegen, das eine Klasse sein muss; nach dem Aufruf B.register(C) gibt der Aufruf issubclass(C, B) True zurück, da B.__subclasscheck__(C) True zurückgibt. Ebenso ist isinstance(x, B) äquivalent zu issubclass(x.__class__, B) or issubclass(type(x), B). (Es ist möglich, dass type(x) und x.__class__ nicht dasselbe Objekt sind, z. B. wenn x ein Proxy-Objekt ist.)

Diese Methoden sind für Aufrufe auf Klassen bestimmt, deren Metaklasse (von) ABCMeta ist; zum Beispiel

from abc import ABCMeta

class MyABC(metaclass=ABCMeta):
    pass

MyABC.register(tuple)

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

Die letzten beiden Asserts sind äquivalent zu den folgenden beiden

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

Natürlich können Sie auch direkt von `MyABC` ableiten

class MyClass(MyABC):
    pass

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

Auch ist ein Tupel natürlich keine MyClass

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

Sie können eine andere Klasse als Unterklasse von MyClass registrieren

MyClass.register(list)

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

Sie können auch eine andere ABC registrieren

class AnotherClass(metaclass=ABCMeta):
    pass

AnotherClass.register(basestring)

MyClass.register(AnotherClass)

assert isinstance(str, MyABC)

Der letzte Assert erfordert das Nachverfolgen der folgenden Ober-/Unterklassen-Beziehungen

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

Das Modul abc definiert außerdem einen neuen Dekorator, @abstractmethod, der zur Deklaration abstrakter Methoden verwendet wird. Eine Klasse, die mindestens eine Methode enthält, die mit diesem Dekorator deklariert wurde und noch nicht überschrieben wurde, kann nicht instanziiert werden. Solche Methoden können von der überschreibenden Methode in der Unterklasse aufgerufen werden (mittels super oder direktem Aufruf). Zum Beispiel

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

Hinweis: Der Dekorator @abstractmethod sollte nur innerhalb eines Klassenkörpers verwendet werden und nur für Klassen, deren Metaklasse (von) ABCMeta ist. Das dynamische Hinzufügen abstrakter Methoden zu einer Klasse oder der Versuch, den Abstraktionsstatus einer Methode oder Klasse zu ändern, sobald sie erstellt wurde, wird nicht unterstützt. @abstractmethod beeinflusst nur Unterklassen, die durch reguläre Vererbung abgeleitet wurden; „virtuelle Unterklassen“, die mit der Methode register() registriert wurden, sind nicht betroffen.

Implementierung: Der Dekorator @abstractmethod setzt das Funktionsattribut __isabstractmethod__ auf den Wert True. Die Methode ABCMeta.__new__ berechnet das Typattribut __abstractmethods__ als die Menge aller Methodennamen, die ein __isabstractmethod__-Attribut mit dem Wert `True` haben. Dies geschieht durch Kombination der __abstractmethods__-Attribute der Basisklassen, Hinzufügen der Namen aller Methoden im neuen Klassenwörterbuch, die ein wahres __isabstractmethod__-Attribut haben, und Entfernen der Namen aller Methoden im neuen Klassenwörterbuch, die kein wahres __isabstractmethod__-Attribut haben. Wenn die resultierende __abstractmethods__-Menge nicht leer ist, gilt die Klasse als abstrakt, und Versuche, sie zu instanziieren, lösen TypeError aus. (Wenn dies in CPython implementiert wäre, könnte ein internes Flag Py_TPFLAGS_ABSTRACT verwendet werden, um diese Prüfung zu beschleunigen [6].)

Diskussion: Im Gegensatz zu abstrakten Methoden in Java oder reinen abstrakten Methoden in C++ können abstrakte Methoden wie hier definiert auch eine Implementierung haben. Diese Implementierung kann über den super-Mechanismus aus der Klasse aufgerufen werden, die sie überschreibt. Dies könnte als Endpunkt für einen Super-Aufruf in einem Framework nützlich sein, das kooperative Mehrfachvererbung verwendet [7], [8].

Ein zweiter Dekorator, @abstractproperty, wird zur Definition abstrakter Datenattribute definiert. Seine Implementierung ist eine Unterklasse der integrierten Klasse property, die ein __isabstractmethod__-Attribut hinzufügt

class abstractproperty(property):
    __isabstractmethod__ = True

Es kann auf zwei Arten verwendet werden

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)

Ähnlich wie bei abstrakten Methoden kann eine Unterklasse, die eine abstrakte Eigenschaft erbt (deklariert entweder mit der Dekoratorsyntax oder der längeren Form), nicht instanziiert werden, es sei denn, sie überschreibt diese abstrakte Eigenschaft mit einer konkreten Eigenschaft.

ABCs für Container und Iteratoren

Das Modul collections wird die für die Arbeit mit Mengen, Mappings, Sequenzen und einigen Hilfstypen wie Iteratoren und Dictionary-Ansichten notwendigen und ausreichenden ABCs definieren. Alle ABCs haben die oben erwähnte ABCMeta als ihre Metaklasse.

Die ABCs bieten Implementierungen ihrer abstrakten Methoden, die technisch gültig, aber ziemlich nutzlos sind; z. B. gibt __hash__ 0 zurück, und __iter__ gibt einen leeren Iterator zurück. Im Allgemeinen repräsentieren die abstrakten Methoden das Verhalten eines leeren Containers des angegebenen Typs.

Einige ABCs bieten auch konkrete (d. h. nicht-abstrakte) Methoden an; beispielsweise hat die Klasse Iterator eine Methode __iter__, die sich selbst zurückgibt und damit eine wichtige Invariante von Iteratoren erfüllt (die in Python 2 von jeder Iterator-Klasse neu implementiert werden musste). Diese ABCs können als „Mix-in“-Klassen betrachtet werden.

Keine in diesem PEP definierten ABCs überschreiben __init__, __new__, __str__ oder __repr__. Die Definition einer Standardkonstruktorsignatur würde benutzerdefinierte Containertypen, z. B. Patricia-Bäume oder gdbm-Dateien, unnötig einschränken. Die Definition einer spezifischen Zeichenkettendarstellung für eine Sammlung bleibt ebenfalls den einzelnen Implementierungen überlassen.

Hinweis: Es gibt keine ABCs für Ordnungsvorgänge (__lt__, __le__, __ge__, __gt__). Die Definition dieser in einer Basisklasse (abstrakt oder nicht) führt zu Problemen mit dem akzeptierten Typ für den zweiten Operanden. Zum Beispiel würde, wenn die Klasse Ordering __lt__ definierte, angenommen, dass für alle Ordering-Instanzen x und y gilt, dass x < y definiert ist (selbst wenn es nur eine partielle Ordnung definiert). Aber das kann nicht der Fall sein: Wenn sowohl list als auch str von Ordering abgeleitet würden, würde dies bedeuten, dass [1, 2] < (1, 2) definiert sein sollte (und vermutlich False zurückgeben würde), während in der Tat (in Python 3000!) solche „Mixed-Mode-Vergleiche“ explizit verboten sind und TypeError auslösen. Siehe PEP 3100 und [14] für weitere Informationen. (Dies ist ein Sonderfall eines allgemeineren Problems mit Operationen, die ein anderes Argument desselben Typs entgegennehmen.)

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__")

Strings

Python 3000 wird wahrscheinlich mindestens zwei integrierte String-Typen haben: Byte-Strings (bytes), die von MutableSequence abgeleitet sind, und (Unicode-)Zeichenketten (str), die von Sequence und Hashable abgeleitet sind.

Offene Punkte: Die Basisinterfaces für diese definieren, damit alternative Implementierungen und Unterklassen wissen, worauf sie sich einlassen. Dies könnte Gegenstand eines neuen PEP oder mehrerer PEPs sein (PEP 358 sollte für den bytes-Typ übernommen werden).

ABCs vs. Duck Typing

Bedeutet die Einführung von ABCs das Ende von Duck Typing? Ich glaube nicht. Python wird nicht verlangen, dass eine Klasse von BasicMapping oder Sequence abgeleitet wird, wenn sie eine __getitem__-Methode definiert, noch wird die x[y]-Syntax verlangen, dass x eine Instanz einer dieser ABCs ist. Sie können immer noch jedes „file-like“-Objekt an sys.stdout zuweisen, solange es eine write-Methode hat.

Natürlich wird es einige Anreize geben, Benutzer zu ermutigen, von den entsprechenden Basisklassen abzuleiten; diese reichen von Standardimplementierungen für bestimmte Funktionalitäten bis hin zu einer verbesserten Möglichkeit, zwischen Mappings und Sequenzen zu unterscheiden. Aber es gibt keine Zwänge. Wenn hasattr(x, "__len__") für Sie funktioniert, großartig! ABCs sind dazu gedacht, Probleme zu lösen, die in Python 2 gar keine gute Lösung haben, wie z. B. die Unterscheidung zwischen Mappings und Sequenzen.

ABCs vs. Generische Funktionen

ABCs sind mit Generic Functions (GFs) kompatibel. Zum Beispiel verwendet meine eigene Generic Functions-Implementierung [4] die Klassen (Typen) der Argumente als Dispatch-Schlüssel, was es abgeleiteten Klassen ermöglicht, Basisklassen zu überschreiben. Da (aus Pythons Sicht) ABCs ganz normale Klassen sind, kann die Verwendung einer ABC in der Standardimplementierung für eine GF sehr angemessen sein. Wenn ich zum Beispiel eine überladene prettyprint-Funktion habe, wäre es sehr sinnvoll, das Pretty-Printing von Sets wie folgt zu definieren

@prettyprint.register(Set)
def pp_set(s):
    return "{" + ... + "}"  # Details left as an exercise

und Implementierungen für spezifische Unterklassen von Set könnten leicht hinzugefügt werden.

Ich glaube, dass ABCs auch keine Probleme für RuleDispatch, Phillips Ebys GF-Implementierung in PEAK [5] darstellen werden.

Natürlich könnten GF-Befürworter behaupten, dass GFs (und konkrete oder Implementierungsklassen) alles sind, was Sie brauchen. Aber selbst sie werden die Nützlichkeit der Vererbung nicht leugnen; und man kann die in diesem PEP vorgeschlagenen ABCs leicht als optionale Implementierungsbasisklassen betrachten; es gibt keine Anforderung, dass alle benutzerdefinierten Mappings von BasicMapping abgeleitet werden müssen.

ABCs vs. Schnittstellen

ABCs sind nicht intrinsisch mit Interfaces inkompatibel, aber es gibt erhebliche Überschneidungen. Vorerst überlasse ich es den Befürwortern von Interfaces, zu erklären, warum Interfaces besser sind. Ich erwarte, dass viel von der Arbeit, die z. B. in die Definition der verschiedenen Abstufungen von „Mapping-Art“ und der Nomenklatur geflossen ist, leicht für einen Vorschlag zur Verwendung von Interfaces anstelle von ABCs adaptiert werden könnte.

„Interfaces“ bezieht sich in diesem Zusammenhang auf eine Reihe von Vorschlägen für zusätzliche Metadaten-Elemente, die einer Klasse zugeordnet sind und nicht Teil der regulären Klassenhierarchie sind, aber bestimmte Arten von Vererbungstests ermöglichen.

Solche Metadaten würden, zumindest in einigen Vorschlägen, so gestaltet sein, dass sie von einer Anwendung leicht geändert werden können, was es Anwendungsentwicklern ermöglicht, die normale Klassifizierung eines Objekts zu überschreiben.

Der Nachteil dieser Idee, mutable Metadaten an eine Klasse anzuhängen, ist, dass Klassen geteilter Zustand sind und ihre Änderung zu Konflikten der Absicht führen kann. Darüber hinaus kann die Notwendigkeit, die Klassifizierung eines Objekts zu überschreiben, mit generischen Funktionen sauberer erledigt werden: Im einfachsten Fall kann eine generische Funktion „Kategorienmitgliedschaft“ definiert werden, die in der Basisimplementierung einfach False zurückgibt, und dann können Überschreibungen bereitgestellt werden, die für alle interessierenden Klassen True zurückgeben.