© Anastasiia Stiahailo / 123RF.com

Die ursprünglich objektorientierte Programmiersprache Python soll in Version 3.10 ein neues, vor allem aus funktionalen Sprachen bekanntes Feature erhalten: das Pattern-Matching. Die Änderung ist in der Community umstritten.

Als Pattern Matching oder Musterabgleich bezeichnet man ein symbolverarbeitendes Verfahren, das anhand eines Musters diskrete Strukturen oder Teilmengen identifiziert, wie etwa Zeichenketten, Bäume oder Graphen. Es findet sich in funktionalen oder logischen Programmiersprachen, die über einen Match-Ausdruck Daten anhand ihrer Struktur verarbeiten, zum Beispiel in Scala [1], Rust [2] und F# [3]. Eine Match-Anweisung nimmt einen Ausdruck und vergleicht ihn mit aufeinanderfolgenden Mustern, die man in Form eines oder mehrerer Fälle (cases) angibt. Dies ähnelt oberflächlich gesehen einer Switch-Anweisung in C, Java oder Javascript, ist aber viel mächtiger.

Python 3.10 soll nun ebenfalls einen solchen Match-Ausdruck erhalten. Das Python Enhancement Proposal PEP 634 [4] beschreibt die Implementierung. Weitere Informationen zu den Plänen finden sich in PEP 635 [5] und PEP 636 [6]. Wie das Pattern Matching in Python 3.10 funktionieren soll, demonstriert das einfache Beispiel in Listing 1, das einen Wert mit mehreren Literalen vergleicht.

def http_error(status):
 match status:
 case 400:
 return "Bad request"
 case 401:
 return "Unauthorized"
 case 403:
 return "Forbidden"
 case 404:
 return "Not found"
 case 418:
 return "I'm a teapot"
 case _:
 return "Something else"

Im letzten Fall der Match-Anweisung fungiert ein Unterstrich als Platzhalter, der alles abfängt. Das hat unter Entwicklern zu Irritationen geführt, da man in Python einen Unterstrich üblicherweise vor Variablennamen verwendet, um sie für den internen Gebrauch zu deklarieren. Zwar unterscheidet Python nicht so strikt wie Java zwischen privaten und öffentlichen Variablen, doch es handelt sich um eine weitverbreitete Konvention, die auch im Style Guide for Python Code [7] festgelegt ist.

Die vorgeschlagene Match-Anweisung kann jedoch nicht nur Muster überprüfen, also eine Übereinstimmung zwischen dem Wert einer Variablen und einem vorgegebenen Muster feststellen, sie bindet die Variablen, die dem angegebenen Muster entsprechen, auch neu. Das führt dazu, dass wir es in Python plötzlich mit Schrödinger-Konstanten zu tun bekommen, die nur so lange konstant bleiben, bis wir sie uns in einer Match-Anweisung genauer anschauen. Das Beispiel in Listing 2 soll das erläutern; die Programmzeilen führen zur Ausgabe aus Listing 3.

NOT_FOUND = 404
retcode = 200
match retcode:
  case NOT_FOUND:
    print('not found')
print(f"Current value of {NOT_FOUND=}")

not found
Current value of NOT_FOUND=200

Dieses Verhalten führt bei erfahrenen Python-Entwicklern wie Brandon Rhodes, Autor unter anderem von “Foundations of Python Network Programming”, zu geharnischter Kritik [8] an dem Vorschlag: “Wenn diese schlecht durchdachte Funktion wirklich zu Python hinzugefügt wird, verlieren wir ein Prinzip, das ich meinen Studenten immer beigebracht habe: Wenn du eine undokumentierte Konstante siehst, kannst du sie immer benennen, ohne die Bedeutung des Codes zu verändern. Das algebraische Substitutionsprinzip? Es gilt dann nicht mehr.”

Viele langjährige Python-Entwickler hadern jedoch nicht nur mit dem strukturellen Pattern Matching, das in Python 3.10 kommen soll. Sie bedauern generell Entwicklungen der letzten Jahre, in denen immer mehr syntaktischer Zucker über die Sprache gestreut worden sei. Ursprüngliche Grundsätze, wie sie im Zen of Python [9] niedergelegt sind, würden vergessen und die Funktionsstabilität ginge verloren. Obwohl Python mit den PEPs [10] einen ausgefeilten Prozess definiert hat, mit dem sich die Weiterentwicklung von Python kollaborativ steuern lässt, kommt es immer wieder zu Kritik auf Twitter und anderen sozialen Medien, wie auch jetzt beim strukturellen Pattern Matching.

Tatsächlich wurde das Thema bereits intensiv in der Python-Community diskutiert. Der Python Steering Council [11] empfahl schon im Dezember 2020 die Annahme des Proposals. Dennoch kochte das Thema erst mit der Annahme des Proposals richtig hoch. Der Grund dafür liegt sicher in der Größe und Vielfältigkeit der Python-Community. Die meisten Programmierer interessieren sich vermutlich nur für Diskussionen, in denen es um Erweiterungen geht, die die eigenen Probleme lösen. Die übrigen Entwicklungen übersieht man, bis die PEPs akzeptiert werden.

So liegt der Fall wohl auch beim strukturellen Pattern Matching. Es ermöglicht Problemlösungen, wie sie vorher in Python kaum möglich waren. So können beispielsweise Data Scientists passende Parser und Compiler schreiben, für die sie bisher auf funktionale oder logische Programmiersprachen ausweichen mussten. Ein einfaches Beispiel findet sich in PEP 635 (Listing 4).