Wofür wir Python einsetzen
Der häufigste Anlass ist ein Umzug. Ein Shop wechselt das System, ein ERP liefert Artikeldaten in einem Format, das niemand mehr pflegt, ein Altsystem gibt seine Bestände nur als Export her. Solche Strecken schreiben wir in Python: einlesen, prüfen, normalisieren, abgleichen, protokollieren. Der Import selbst ist selten das Problem. Das Problem sind die Datensätze, die nicht in das Schema passen und die trotzdem jemand vermissen wird.
Der zweite Bereich ist Automatisierung. Berichte, die jemand sonst jeden Montag von Hand zusammenklickt. Abgleiche zwischen Shop, Warenwirtschaft und Buchhaltung. Prüfungen, die auffallen sollen, bevor der Kunde sie meldet. Dazu kommt seit einigen Jahren die Anbindung von Sprachmodellen: Dokumente einlesen, Inhalte klassifizieren, Texte vorstrukturieren, Ergebnisse in ein bestehendes System zurückschreiben. Python hat für diese Aufgaben die Bibliotheken, die es anderswo nicht gibt, und das ist der Grund, aus dem wir es wählen.
Wie wir damit arbeiten
Jedes Skript, das mehr als einmal laufen soll, bekommt eine feste Umgebung. Abhängigkeiten werden gepinnt, die Ausführung läuft im Container, Zugangsdaten stehen nicht im Code. Für Datenarbeit nutzen wir pandas, für Anbindungen requests und die jeweiligen SDKs, für Web-Endpunkte FastAPI. Formatierung übernimmt Ruff, Typprüfung mypy, wo es sich lohnt. Nichts davon ist originell. Genau deshalb funktioniert es auch noch, wenn zwei Jahre später jemand anderes hineinsieht.
Migrationsskripte schreiben wir so, dass sie mehrfach laufen können, ohne Schaden anzurichten. Erst ein Durchlauf ohne Schreibzugriff, der zeigt, was passieren würde. Dann der echte Lauf mit Protokoll. Datenaufbereitung wird versioniert wie Anwendungscode, weil die Frage „welche Regel hat diesen Wert erzeugt“ ein halbes Jahr später sicher gestellt wird. Wer Datenarbeit als einmalige Aktion plant, plant sie zweimal.
Grenzen und wann wir davon abraten
Python ist nicht unsere Sprache für Webanwendungen. Wenn ein Shop, ein Portal oder eine Fachanwendung entsteht, bauen wir sie mit PHP 8 und Symfony — nicht weil Django schlecht wäre, sondern weil unser Betrieb, unser Hosting und unsere Erfahrung dort liegen. Eine Anwendung in einer Sprache zu bauen, die im Haus nur zweite Wahl ist, rächt sich im dritten Jahr, wenn sie jemand ändern muss.
Auch bei Datenaufgaben gibt es Grenzen. Wenn eine Auswertung nur Zahlen aus einer Datenbank zusammenzieht, ist SQL die kürzere Antwort. Wenn eine Automatisierung fest im Shop hängt und dessen Regeln braucht, gehört sie als Kommando in die Anwendung selbst, nicht in ein separates Skript. Und jeder Python-Dienst, der dauerhaft läuft, ist ein weiteres Stück Betrieb: Updates, Überwachung, Zuständigkeit. Wir sagen das vorher, nicht in der Abnahme.