NumPy ist seit Jahren ein integraler Bestandteil der Python-Programmierwelt, insbesondere für die Arbeit mit numerischen Arrays und mathematischen Operationen. Es gilt als eine der beliebtesten Bibliotheken für wissenschaftliches Rechnen und hat maßgeblich die Entwicklung zahlreicher maschineller Lernbibliotheken wie PyTorch beeinflusst. Trotz seiner großen Verbreitung und Beliebtheit gibt es berechtigte Kritikpunkte und Herausforderungen, die viele Anwender im Alltag erleben – auch ich habe lange Zeit Schwierigkeiten und Frustrationen mit NumPy verspürt. In diesem Text teile ich meine Gedanken dazu, warum ich NumPy nicht mag und welche Probleme insbesondere bei komplexeren Aufgaben auftreten. NumPy macht einfache Dinge problemlos und elegant. Wenn man eine einfache lineare Gleichung Ax = y lösen möchte, mit A als 5×5-Matrix und x als Vektor der Länge 5, funktioniert das sehr komfortabel und klar mit der Funktion np. linalg. solve.
Der klare und ausdrucksstarke Code ist tatsächlich ein Grund für den Erfolg von NumPy. Doch sobald komplexere oder höherdimensionale Aufgaben anstehen, beginnt die Unübersichtlichkeit. Ein häufiges Problem ist das Arbeiten mit Stapeln von Matrixgleichungen, etwa wenn man 100 Matrizen und 100 Vektoren gleichzeitig bearbeiten will. Die intuitive Lösung wäre ein einfacher Schleifenmechanismus, der im Code leicht verständlich ist. Python wiederum ist bekannt dafür, dass Schleifen bei großen Daten sehr langsam sind – darum legt NumPy den Fokus auf vektorisierten Code und parallele GPU-Berechnungen. Wegen dessen erfordert die Lösung solcher Probleme, etwa das gleichzeitige Lösen von 100 Gleichungssystemen, eine Ausnutzung der vorhandenen Spezialfunktionen auf nicht ganz offensichtliche Weise. Denn die reguläre Schnittstelle von np. solve ist eigentlich für 2D-Arrays und 1D- oder 2D-Vektoren ausgelegt, nicht aber für Stapel höherer Dimension.
Was darauf folgt, ist ein Unsicherheitsmoment, in dem nicht klar ist, wie genau man die Daten mit den Dimensionen richtig gestalten muss, um die parallele Lösung auszuführen. Die Dokumentation bietet dazu kaum direkte Hilfestellung. Eigenes Experimentieren mit unterschiedlichen Transpositionen, Dimensionserweiterungen und Achsenparametern bringt oft Ergebnisse, aber keine Gewissheit. So entsteht der Eindruck, niemand weiß wirklich, was zu tun ist, und man probiert so lange herum, bis es funktioniert. Das ist unbefriedigend, ineffizient und eröffnet eine Fehlerquelle in der Entwicklung. Ein weiteres Kernproblem ist die eher kryptische Methode der Broadcast-Mechanismen in NumPy. Das Prinzip besagt, dass Arrays unterschiedlicher Dimensionen operieren können, wenn die fehlenden Dimensionen als 1 interpretiert und entsprechend für die Operation gestreckt werden. In einfachen Fällen ist das intuitiv, etwa wenn man eine Matrix mit einem Vektor multipliziert.
Doch sobald man komplexere Dimensionen kombiniert, wird die Verwendung von None-Anweisungen (um Dimensionen einzufügen) zur Monsteraufgabe. Die Vermischung von neuen Dimensionen, Broadcasting-Regeln und darauf aufbauenden Operationen lässt ziemlich schnell den Überblick verschwinden. Die Konsequenz ist oft, dass einfache mathematische Operationen, wie etwa das Berechnen eines gewichteten Mittelwertes über verschiedene Achsen mit mehreren Arrays in hoher Dimension, wie z. B. mit der Kombination von K×L×M-, L×N- und K×M-Arrays, fast unlesbar und komplex werden. Die Alternativlösung mit np. tensordot ermöglicht zwar eine kompaktere Syntax, aber ist ohne intensive Auseinandersetzung schwer nachvollziehbar. Selbst erfahrene Entwickler brauchen oft lange, um den Code zu verstehen und Fehler zu vermeiden.
Gerade diese Komplexität macht NumPy-Code nicht nur schwer lesbar sondern auch anfälliger für Fehler – zu oft führt eine kleine Fehleinschätzung bei der Dimension oder Achsreihenfolge zu falschen Ergebnissen. Für komplexe Projekte heißt das, dass die Entwicklungszeit steigt. Dabei wäre gerade bei datenwissenschaftlichen Projekten Übersichtlichkeit und Transparenz besonders wichtig, denn Datenoperationen sind das Herzstück. Ein Lichtblick im NumPy-Universum ist die Funktion np. einsum, die auf dem Konzept der Einstein-Summenkonvention basiert. Mit Einsum kann man klar und explizit mittels Indexnotation angeben, welche Dimensionen multipliziert und welche summiert werden sollen. Das macht komplexe Berechnungen vergleichsweise lesbar und verständlich – wenn man sich an die Syntax gewöhnt hat. Dieses Konzept bringt den Vorteil mit sich, dass man komplexe Verkettungen mit wenigen Zeichen ausdrücken kann, ohne tief verschachtelte Broadcasting-Tabellen verstehen zu müssen.
Es wäre wünschenswert, wenn mehr Funktionen in NumPy nach diesem Modell gestaltet wären. Doch einsum bleibt ein Spezialwerkzeug, kein Allheilmittel. Neben Broadcasting und der mathematischen Operationen stößt man bei NumPy schnell auf Schwierigkeiten bei der Indexierung. Was in einfachen Fällen noch logisch erscheint, wird mit der Kombination von Arrays im Indexierungsbereich zu einem echten Rätsel. Beispielsweise führen gleichzeitige Indizes aus unterschiedlichen Arrays zu Broadcasts und Permutationen unbekannter Dimensionen. Die resultierenden Formen des zurückgegebenen Arrays folgen komplexen Regeln, die auch von Experten häufig falsch interpretiert werden. Für Menschen, die Algorithmen oder Modelle nachvollziehen und anpassen wollen, ist das eine erhebliche Hürde.
Das führt bei vielen Anwendern zu einem Zustand, der als eine Art „Stockholm-Syndrom der NumPy-Anwender“ beschrieben werden könnte – man gewöhnt sich durch die häufige Anwendung an die Umständlichkeit, statt sie abzuschaffen. Andere Programmiersprachen und Frameworks versuchen hier alternativ Indexnotationen zu verwenden, die sich besser an „menschliche“ Intuition anlehnen, zum Beispiel Julia oder leistungsfähige Domain-Specific Languages (DSLs). Im Vergleich hinkt NumPy damit hinterher, auch wenn der Python-Ökosystem-Vorteil nicht zu unterschätzen ist. Wenn man die Vielzahl an Funktionen betrachtet, zeigt NumPy eine teilweise inkonsistente API-Design-Philosophie. So gibt es Funktionen, die diverse Achsenargumente anbieten, andere wiederum nicht, wieder andere haben unterschiedliche Namen für etwas ähnliche Operationen. Es gibt Fälle, in denen man auf bestimmte Konventionen angewiesen ist, die nicht immer logisch klar oder dokumentiert sind.
Diese Uneinheitlichkeit führt dazu, dass man oft Funktionen neu implementieren oder anpassen muss, nur um sie auf andere Dimensionen oder Datenformen anwendbar zu machen. Das widerspricht grundlegenden Prinzipien der Softwareentwicklung, die auf abstrahiertes, wiederverwendbares und wartbares Programmieren setzen. Ein praktisches und oft diskutiertes Beispiel ist der Bereich der Selbst-Attention-Mechanismen, welche die Grundlage moderner Sprachmodelle wie GPT darstellen. Eine einfache Version mit NumPy ist noch recht klar implementierbar, doch sobald man zu Multi-Head-Attention übergeht, wird der Code beinahe unlesbar, weil man alle Kopf-Operationen parallel und verschachtelt darstellen muss, meist mittels komplexer Einstein-Summensyntax und aufwendigem Reorganisieren der Array-Dimensionen. Der programmierte fließtextbasierte Loop fehlt, weil er zu langsam wäre – das Resultat ist schwer nachvollziehbarer, "cleverer" Code, der die menschliche Lesbarkeit zugunsten der Effizienz opfert.
Zusammengefasst lässt sich sagen, dass zumindest aus Sicht vieler Entwickler NumPy durchaus leistungsfähig und in seinen Grundideen elegant ist, allerdings an einigen elementaren Punkten scheitert: Es macht viele einfache Dinge einfach gut, aber sobald die Anforderungen komplexer werden, scheitert die Lesbarkeit, Wartbarkeit und intuitive Nutzbarkeit. Die Kernprobleme liegen in der Idee des Broadcastens als Ersatz für echte Indizes, in der inkonsistenten Funktions-API und in der beschwerlichen Indexierung. Daher liegt der Wunsch nach einer modernen, übersichtlichen und gleichzeitig GPU-effizienten Array-Bibliothek nahe, die explizite Indizes verwendet, einen einfachen Zugang zu parallelen Berechnungen bietet und den Programmierer nicht zwingend zu umständlichen Tricks und Konventionen zwingt. Einige Projekte und Sprachen versuchen das, doch NumPy bleibt wegen seiner Verbreitung und Komponentenvielfalt weiterhin der Standard.
Die Kunst besteht also darin, erweiterte Funktionalität mit einer verständlichen und lesbaren Syntax zu verbinden – und genau das verspricht eine neue Generation von Array-Sprachen und Bibliotheken. Für alle, die täglich mit komplexen Datentransformationen im Python-Universum arbeiten, bleibt NumPy daher ein Werkzeug mit starken Seiten, aber auch bedeutenden Schwächen. Sich dessen bewusst zu sein, hilft dabei, bessere Entscheidungen beim Design von Softwarearchitekturen zu treffen und gegebenenfalls Alternativen oder Ergänzungen in Betracht zu ziehen.
