Protocol-Klassen: strukturelle Typisierung für duck-typed Python

Worum es geht

Eine Protocol-Klasse (PEP 544, typing.Protocol) listet Methoden und Attribute auf; jedes Objekt, das sie bereitstellt, erfüllt den Typ, unabhängig davon, ob seine Klasse vom Protokoll erbt. Die typing-Dokumentation nennt das strukturelle Subtypisierung (statisches Duck-Typing), im Gegensatz zu nominaler Subtypisierung über Vererbung. Die «One-Trick-Ponys» in collections.abc wie Iterable und Sized sind die eigenen Beispiele der Standardbibliothek. Ein Protokoll kann generisch sein (class Reader[T](Protocol) ab Python 3.12, Protocol[T] davor).

Warum es wichtig ist

Funktionen, die «irgendetwas mit .read()» oder «irgendetwas mit .close()» entgegennehmen, sind in Python allgegenwärtig. Ohne Protokolle werden sie als Any annotiert (keine Prüfung) oder als eine konkrete Klasse (Aufrufende müssen davon erben). Ein Protokoll lässt die konsumierende Stelle festlegen, was sie braucht, statt dass die erzeugende Stelle festlegt, was sie ist: Der Typ liegt neben dem Code, der von ihm abhängt, Klassen von Drittanbietern passen ohne Änderung, und ein Test-Double braucht nur die tatsächlich verwendeten Mitglieder.

So wird es angewendet

• Das Protokoll im konsumierenden Modul definieren und minimal halten: nur die Mitglieder, die die konsumierende Stelle aufruft, mit präzisen Signaturen und ...-Rümpfen.
• Protokolle für Parametertypen verwenden und abstrakte Basisklassen für geteilte Implementierung; ein Protokoll trägt keinen Code, eine ABC kann welchen tragen.
• @runtime_checkable nur dort ergänzen, wo isinstance() wirklich gebraucht wird. Die Dokumentation hält fest, dass solche Prüfungen nur das Vorhandensein der gegebenen Attribute testen und deren Typsignaturen ignorieren; Protokolle ohne den Decorator lassen sich mit isinstance() überhaupt nicht verwenden.
• Protokolle nach Fähigkeit benennen (SupportsClose, Closable), passend zu typing.SupportsInt und Ähnlichem.
• Konformität dort statisch prüfen, wo Drift schaden würde. PEP 544 hält fest, dass explizites Subklassieren für die Typprüfung nicht nötig ist, dass es dem Checker aber erlaubt, die Klasse bei ihrer Definition zu verifizieren, und ihr Standardimplementierungen gibt. Die Alternative, eine Instanz einer mit dem Protokoll annotierten Variablen zuzuweisen, funktioniert ebenfalls; das PEP rät im Anwendungscode davon ab, weil es wie toter Code wirkt und eine Instanz braucht – also in einem Testmodul belassen.

Stolpersteine

Attribut-Mitglieder (name: str) werden sowohl von einfachen Attributen als auch von Properties erfüllt, aber ein Checker verwirft eine schreibgeschützte Property dort, wo ein setzbares Attribut deklariert ist. Eine Methode, deren Parameternamen von denen des Protokolls abweichen, kann als inkompatibel gemeldet werden, weil Aufrufende sie per Schlüsselwort übergeben könnten; Parameter als nur-positional markieren (/), wo Namen nicht Teil des Vertrags sind. Die Dokumentation merkt an, dass eine isinstance()-Prüfung gegen ein zur Laufzeit prüfbares Protokoll überraschend langsam gegenüber einer Klassenprüfung sein kann, und dass erst in __init__ zugewiesene Attribute den Vorhandenseinstest verfehlen, bis sie gesetzt sind. Protocol-Klassen lassen sich nicht instanziieren. Explizites Erben von einem Protokoll ist erlaubt, aber Lesende sehen dann eine nominale Beziehung, wo keine nötig war.