Python: Die Sprache, die nicht rechnen musste

Weihnachten 1989. Amsterdam liegt im Feiertagsschlaf, das Centrum Wiskunde & Informatica ist geschlossen, und Guido van Rossum hat eine freie Woche, mit der er nichts anzufangen weiß. Kein Auftrag, keine Deadline, nur die Unzufriedenheit eines Systemprogrammierers, der am verteilten Betriebssystem Amoeba schreibt und dabei ständig das Gefühl hat, mehr Zeit mit der Sprache C zu verbringen als mit dem eigentlichen Problem. Er beginnt ein Hobbyprojekt: einen Nachfolger der Lehrsprache ABC, lesbarer als ein Shell-Skript, zugänglicher als C. Den Namen findet er, ohne lange zu suchen, bei seiner britischen Lieblingscomedy-Truppe (1). Im Februar 1991 veröffentlicht er den Quellcode in einer Usenet-Gruppe. Niemand in diesem Moment hätte behauptet, hier entstehe die Sprache, die 35 Jahre später zur bevorzugten Oberfläche der künstlichen Intelligenz werden würde.

In den Neunzigerjahren galt Python als das, was es auch sein sollte: eine Skriptsprache. Man nahm sie für Systemadministration, für kleine Werkzeuge, für alles, was schnell geschrieben und selten optimiert werden musste. Wer ernsthaft rechnete, blieb bei Fortran oder C, den Sprachen, die der Maschine nahe waren und ihr wenig zumuteten. Python tat das Gegenteil: Es zumutete der Maschine einiges, zugunsten der Lesbarkeit für den Menschen, der es schrieb. Die eingebaute Einrückungssyntax, die vielen als Marotte erschien, war genau das Programm dahinter. Van Rossum selbst nannte das Ziel später ausführbaren Pseudocode: Der Code sollte aussehen wie sein eigener Kommentar. Im Zen of Python, der kleinen Sammlung von Designprinzipien, die bis heute jeder Python-Interpreter auf Wunsch ausgibt, steht dazu der Satz, der alles trägt: Lesbarkeit zählt.

Das war, gemessen an der Konkurrenz, eine seltsame Priorität. Eine Sprache, die zugunsten des Lesers auf Rechengeschwindigkeit verzichtet, hatte in einer Disziplin, die sich seit ihrer Gründung über Flops und Taktzyklendefinierte, eigentlich keine Zukunft. Dass sie trotzdem eine bekam, lag nicht an Python selbst, sondern an einer Gemeinschaft, die eine andere Priorität hatte als die Systemprogrammierer.

Schon 1995 schrieb Jim Hugunin ein Paket namens Numeric, das Python beibrachte, mit großen Zahlenfeldern umzugehen, wie es Fortran seit Jahrzehnten konnte (2). Es war ein Nischenwerkzeug für eine Nischenzielgruppe, Physiker und Ingenieure, die eigentlich Matlab benutzten, sich dessen Lizenzkosten aber nicht leisten wollten oder konnten. 2001 bündelten Travis Oliphant, Eric Jones und Pearu Peterson eigene Erweiterungen zu SciPy, einer Sammlung numerischer Verfahren für Optimierung, lineare Algebra und Signalverarbeitung (3). Ebenfalls 2001 veröffentlichte Fernando Pérez IPython, eine interaktive Kommandozeile, aus der 2014 das Jupyter-Projekt hervorging – eine Umgebung, in der Code, Daten, Visualisierung und Erklärung selbstverständlich in einem einzigen Dokument zusammenfinden (4). Aus Numeric und einem konkurrierenden Fork namens Numarray formte Oliphant 2005 zusätzlich ein einziges, wiedervereintes Paket: NumPy (5). 2003 kam mit Matplotlib eine Bibliothek für Diagramme dazu, die aussahen wie aus einer wissenschaftlichen Publikation, weil sie genau dafür gemacht war (6). Und 2008 begann Wes McKinney, seinerzeit Analyst beim Hedgefonds AQR Capital Management, aus schlichtem Frust über fehlende Werkzeuge zur Auswertung von Finanzzeitreihen eine Bibliothek namens pandas zu schreiben, benannt nach dem ökonometrischen Fachbegriff Panel Data (7).

Was diese Namen gemeinsam haben, ist unspektakulär und deshalb entscheidend: Sie lösten keine Probleme der künstlichen Intelligenz. Sie lösten Probleme der Statistik, der Finanzanalyse, der Signalverarbeitung. Ein ganzes akademisches und quantitatives Ökosystem gewöhnte sich an Python, Jahre bevor Deep Learning zum dominanten Forschungsparadigma wurde. Als der KI-Boom kam, fand er also keine leere Werkbank vor, sondern eine, auf der Werkzeuge für exakt die Aufgabe herumlagen, die als nächste anstand: mit riesigen Zahlenfeldern rechnen, sie visualisieren, sie in Tabellen sortieren, das Ergebnis interaktiv nachprüfen.

Die These, dass Python zur Sprache der KI wurde, ist genau genommen ungenau. Python wurde zur Oberfläche der KI, während die eigentliche Rechenlast in einer anderen Sprache stattfand. NumPy selbst arbeitet innen mit kompiliertem Code, außen wird es aus Python bedient; der Interpreter dirigiert, die Schleifen laufen woanders. Als NVIDIA Ende 2006 die Programmierplattform CUDA vorstellte und Anfang 2007 als öffentliche Beta für Entwickler freigab, öffnete sich dieselbe Arbeitsteilung für Grafikkarten (8). Eine GPU, ursprünglich zum Rendern von Polygonen gebaut, konnte nun für beliebige parallele Berechnungen genutzt werden, solange jemand den Code in C oder C++ schrieb, der ihr die Rechenschritte vorgab. Der eigentliche Gewinn lag im Gegenteil: Python übernahm keine zusätzliche Rechenarbeit, es verbarg sie. Unter wenigen lesbaren Zeilen verschwanden Speicherverwaltung, Vektoroperationen und irgendwann ganze GPU-Cluster. Wer mit NumPy arbeitete, musste immer weniger darüber nachdenken, wie die Maschine rechnete, und konnte sich stärker damit befassen, was sie rechnen sollte.

Der Moment, der diese Arbeitsteilung für die Öffentlichkeit sichtbar machte, kam 2012, und er enthält eine kleine Pointe, die selten erzählt wird. Alex Krizhevsky, Ilya Sutskever und Geoffrey Hinton gewannen den ImageNet-Wettbewerb mit einem neuronalen Netz, das später AlexNet hieß, und drückten die Top-5-Fehlerrate des bis dahin besten Ansatzes von 26,2 auf 15,3 Prozent (9). Es war der Beweis, dass tiefe neuronale Netze auf GPUs trainiert echte Probleme lösen konnten. Geschrieben war dieser Code, Krizhevskys eigenes Framework cuda-convnet, direkt in CUDA und C++, ursprünglich für kleinere Bilddatensätze entwickelt und dann auf ImageNet skaliert. Python spielte bei diesem Durchbruch noch keine tragende Rolle. Der Durchbruch, der die gesamte spätere Python-Dominanz erst plausibel machte, fand ohne Python statt.

Was danach kam, war die eigentliche Weichenstellung. Im November 2015 veröffentlichte Googles Forschungsabteilung Google Brain TensorFlow, ein Framework, das Python-Code entgegennahm und ihn in einen Berechnungsgraphen übersetzte, der auf CPU, GPU oder Googles eigenen TPUs ausgeführt wurde (10). 2016 begann Facebooks KI-Forschungslabor mit der Entwicklung eines Gegenstücks, im Januar 2017 wurde PyTorch öffentlich vorgestellt (10). Beide Frameworks lösten dasselbe Problem wie NumPy zuvor, nur eine Größenordnung ambitionierter: Sie ließen Forschende in einer lesbaren Hochsprache denken, während im Hintergrund C++ und CUDA rechneten.

Der entscheidende Unterschied zwischen den beiden lag zunächst weniger im Rechenkern als in der Ergonomie für den Menschen. PyTorch erlaubte von Anfang an, das Netz Schritt für Schritt aufzubauen und dabei mit gewöhnlichen Python-Debuggern hineinzuschauen, das damalige TensorFlow 1.x verlangte, den gesamten Graphen vorab zu definieren, bevor überhaupt gerechnet wurde. Für eine Forschungsgemeinschaft, die ausprobierte, bevor sie produzierte, war das mehr als ein technisches Detail: Es entschied, welches Werkzeug sich wie ein Gedanke anfühlte und welches wie ein Formular.

An dieser Stelle schließt sich der Kreis zu Weihnachten 1989. Van Rossums Entscheidung, Lesbarkeit über Rechengeschwindigkeit zu stellen, war reine Kontingenz einer leeren Feiertagswoche, keine Strategie für diesen Moment. Aber sie erwies sich, drei Jahrzehnte später, als exakt die Eigenschaft, die eine Forschungsgemeinschaft brauchte, die schneller denken wollte, als sie rechnete.

Von hier aus lief ein Mechanismus, der sich selbst verstärkte, ohne dass ihn jemand eigens hätte anschieben müssen. Immer mehr neue Bibliotheken für maschinelles Lernen bekamen eine Python-Schnittstelle oder wurden gleich direkt für Python entwickelt, weil dort schon NumPy, pandas und Matplotlib lagen. Studierende lernten Python, weil dort die Werkzeuge für ihre Abschlussarbeit lagen. Universitäten nahmen Python zunehmend in ihre Einführungskurse auf, und jede neue Kohorte trug die Sprache weiter. Entscheidend war dabei stets die Sprache, die die Nutzer zu sehen bekamen, kaum je die Sprache im Innern des Werkzeugs. Dieser Kreislauf lässt sich nicht mehr auf eine einzelne Entscheidung zurückführen, er trägt sich seit Jahren selbst.

Wer heute die Werkzeugliste der Branche durchgeht, findet dieselbe Handschrift wie 2015: PyTorch, TensorFlow, JAXund Hugging Face Transformers sind für Modellentwicklung, Training und Forschung Python-first, scikit-learn für klassisches maschinelles Lernen ohnehin, und auch die Data-Pipelines dahinter laufen in aller Regel über NumPy und pandas. Aufschlussreicher ist die zweite Beobachtung: Auch die SDKs von OpenAI, Anthropic und Google bieten zwar mehrere Sprachen an, aber Python bleibt darunter durchgängig die zentrale, bevorzugte Schnittstelle. Selbst in der neuen Ära, in der Modelle zunehmend über APIs konsumiert statt selbst trainiert werden, bleibt Python eine der wichtigsten Zugangssprachen. Es ist derselbe Netzwerkeffekt, der sich unter neuen Namen fortsetzt.

Das Ergebnis lässt sich in nüchternen Zahlen ablesen, auch wenn jeder Index nur einen Ausschnitt zeigt. Der TIOBE-Index misst die allgemeine Sichtbarkeit von Programmiersprachen über große Suchmaschinen hinweg und führte Python im August 2026 mit 18,53 Prozent an, weit vor C auf Platz zwei (11) – ausdrücklich ohne dabei Codequalität oder tatsächliche Nutzung zu messen. Der PYPL-Index misst etwas anderes, nämlich wie oft gezielt nach Sprach-Tutorials gesucht wird, und zeigt dort eine noch deutlichere Python-Dominanz (12). Beide Indizes messen Verschiedenes. Beide zeigen aus unterschiedlichen Perspektiven, wie groß Pythons Vorsprung inzwischen geworden ist. Python ist heute nicht deshalb die Sprache der KI, weil es schnell ist, sondern weil eine ganze Generation von Forschenden und Lernenden in ihr denken gelernt hat, während anderswo gerechnet wurde.

Diese Pointe ist auch eine leise Ironie der Technikgeschichte: Die Sprache, die als zu langsam für ernsthafte Berechnungen galt, wurde zur Sprache der rechenintensivsten Disziplin überhaupt, indem sie sich weigerte, selbst zu rechnen. Sie delegierte, dirigierte, blieb lesbar.