Die Lernlisten, die man im Netz zu "Python für Data Science" findet, haben ein gemeinsames Problem: Sie sind zu lang und an den falschen Stellen zu tief. Sie führen Dekoratoren, Generatoren und asynchrone Programmierung auf, aber selten das, woran im Praktikum tatsächlich die Tage vergehen - eine Datei einlesen, die nicht so aussieht wie beschrieben, und eine Fehlermeldung verstehen, die auf drei Ebenen verschachtelt ist.
Dieser Text sortiert den Stoff nach dem, was im Alltag eines KI-Teams gebraucht wird: ein Pflichtprogramm, eine zweite Stufe, und ein Stapel Themen, die warten können.
Das Pflichtprogramm
Fünf Dinge musst du sicher beherrschen. Sicher heißt: ohne nachzuschlagen, wie die Syntax geht, und ohne bei einem unerwarteten Ergebnis ratlos zu sein.
Datenstrukturen und was sie kosten. Listen, Dictionaries, Mengen, Tupel. Wichtiger als die Syntax ist das Gefühl dafür, wann welche passt: Wenn du in einer Schleife prüfst, ob ein Wert schon vorkam, gehört das in eine Menge oder ein Dictionary, nicht in eine Liste. Der Unterschied fällt bei tausend Zeilen nicht auf und bei zwei Millionen sehr wohl - und mit zwei Millionen Zeilen arbeitest du im Praktikum eher, als du denkst.
Funktionen, die eine Sache tun. Argumente, Rückgabewerte, Standardwerte. Und die Angewohnheit, eine Funktion zu schreiben, sobald derselbe Block zum zweiten Mal auftaucht. Wer das nicht tut, sitzt am Ende vor einem Notebook mit vierzig Zellen, in dem dieselbe Bereinigung viermal steht - dreimal richtig und einmal, mit einer Zahl, die jemand vergessen hat mitzuändern.
Dateien einlesen, in allen Zuständen. CSV mit dem falschen Trennzeichen, CSV mit Semikolon und deutschem Dezimalkomma, JSON mit verschachtelten Objekten, Excel-Dateien mit drei Kopfzeilen über der eigentlichen Tabelle, eine Textdatei in einer Zeichenkodierung, die niemand dokumentiert hat. Das ist keine anspruchsvolle Programmierung, aber es ist der Anfang von fast jeder Aufgabe. Wer hier flüssig ist, spart pro Woche einen halben Tag.
Fehler lesen. Ein Traceback liest man von unten nach oben: unten steht, was passiert ist, darüber, wo. Der Unterschied zwischen KeyError, TypeError und ValueError sagt dir bereits, in welche Richtung du suchst. Wer eine Fehlermeldung als Wand wahrnimmt und sie ungelesen in eine Suchmaschine kopiert, verliert die wichtigste Information, die er hat. Diese Fähigkeit ist nebenbei die, die im Gespräch am schnellsten auffällt - mehr dazu im Leitfaden zum technischen Gespräch.
Die Datenbibliotheken für Tabellen und Zahlen. Ein Datenrahmen ist eine Tabelle mit Namen für Zeilen und Spalten. Du musst darin auswählen, filtern, gruppieren, aggregieren und zwei Tabellen zusammenführen können. Beim numerischen Unterbau reicht ein Grundverständnis für Arrays, Dimensionen und dafür, dass Operationen auf ganzen Spalten schneller sind als eine Schleife über Zeilen. Diese beiden Bibliotheken sind zusammen mit SQL das tägliche Werkzeug in fast jedem datennahen Team; wie sich beides ergänzt, steht im Beitrag zu SQL für KI-Praktika.
Dazu kommt: ein Notebook bedienen, ohne darin zu wohnen. Notebooks sind hervorragend, um etwas anzuschauen, und schlecht, um etwas zu bauen. Wer den Unterschied kennt, ist einer Menge Ärger aus dem Weg.
Die zweite Stufe
Diese vier Punkte trennen jemanden, der Python kann, von jemandem, mit dem man im Team arbeiten kann. Wenn du sie vor dem Praktikum nicht schaffst, lernst du sie in den ersten Wochen - dann aber unter Zeitdruck.
Virtuelle Umgebungen und Abhängigkeiten. Jedes Projekt bekommt seine eigene Umgebung, und was darin installiert ist, steht in einer Datei, die mit ins Repository geht. Der Satz "bei mir läuft es" ist in einem Team keine Aussage, sondern ein Problem.
Code aus dem Notebook in Dateien überführen. Die Bewegung ist immer dieselbe: Was funktioniert, wandert in eine Funktion, die Funktion wandert in eine .py-Datei, das Notebook importiert sie und behält nur noch die Aufrufe und die Diagramme. Danach ist der Code prüfbar, wiederverwendbar und vergleichbar. Vorher ist er eine Erzählung.
Einfache Tests. Kein Testframework in der Tiefe, sondern die Gewohnheit, für eine Funktion, die etwas berechnet, zwei oder drei Fälle festzuhalten: einen normalen, einen leeren, einen kaputten. Das dauert zehn Minuten und fängt genau die Fehler, die sonst erst in der Auswertung auffallen, wenn niemand mehr weiß, welche Version die Zahlen erzeugt hat.
Git im Alltag. Nicht die Theorie, sondern die fünf Handgriffe: Änderungen ansehen, festschreiben, hochladen, einen Zweig anlegen, einen Konflikt auflösen, ohne in Panik zu geraten. Git ist auch der Grund, warum dein öffentliches Profil bei einer Bewerbung so viel Gewicht hat - dazu der Portfolio-Leitfaden.
Was du getrost später lernst
| Thema | Warum es warten kann |
|---|---|
| Nebenläufigkeit, Threads, asynchrone Programmierung | Im Praktikum bist du selten der, der Parallelisierung entwirft. Wo Durchsatz zählt, übernehmen das Werkzeuge und die Plattform. |
| Metaprogrammierung, Dekoratoren, Metaklassen | Du wirst Dekoratoren lesen müssen, in Testcode und in Web-Bibliotheken. Selbst schreiben musst du keine. |
| Eigene Pakete bauen und veröffentlichen | Interessant, sobald du etwas hast, das andere nutzen sollen. Vorher ein Selbstzweck. |
| Typisierung in der Tiefe | Typannotationen an Funktionssignaturen sind hilfreich und in zwanzig Minuten gelernt. Das darüber liegende System aus generischen Typen und Protokollen brauchst du erst in großen Codebasen. |
| Objektorientierung als Selbstzweck | Klassen verstehen: ja. Vererbungshierarchien entwerfen: in der Datenarbeit fast nie nötig. |
Das heißt nicht, dass diese Themen unwichtig wären. Es heißt, dass sie in der Reihenfolge weiter hinten stehen - und dass niemand dich in einem Praktikum danach fragt, während du gleichzeitig an einer verschachtelten JSON-Datei scheiterst.
Der Unterschied, der wirklich auffällt
Nach ein paar Wochen im Team zeigt sich, dass die auffälligste Trennlinie gar nicht beim Wissen verläuft.
Die einen schreiben Code, der funktioniert, solange man die Zellen in genau der richtigen Reihenfolge ausführt, in dem Variablen df2, df_neu und df_neu2 heißen und in dem ein Schwellenwert an vier Stellen als Zahl steht. Der läuft am Tag der Abgabe. Am Tag danach nicht mehr, und niemand außer dem Autor kann sagen, warum.
Die anderen schreiben Code, in dem Dinge heißen, wie sie sind, in dem Pfade und Schwellenwerte oben stehen und nicht mittendrin, der von oben nach unten durchläuft und in dem an den drei nicht offensichtlichen Stellen ein Satz Kommentar steht, warum es so und nicht anders gemacht wurde. Dieser Code ist meist unspektakulärer. Er wird übernommen.
Elegante Einzeiler sind kein Ziel. Eine Zeile, in der drei Bedingungen, zwei Umformungen und eine Aggregation stecken, ist eine Zeile, die niemand ändern will - auch du nicht, in vier Wochen. Was zählt, ist Code, der am nächsten Tag noch läuft und von jemand anderem gelesen werden kann. Die Rollen, in denen das am stärksten durchschlägt, sind die datennahen; ein Blick in das Berufsfeld Daten und Analytics zeigt, wie unterschiedlich der Anteil an Programmierung dort ausfällt.
Wie viel Python welche Rolle braucht
Der nötige Umfang hängt davon ab, wohin du willst. Ein Data Analyst kommt mit dem Pflichtprogramm und viel SQL weit; das Gewicht liegt auf Auswertung und Darstellung. Ein Data Scientist braucht dasselbe plus die Modellbibliotheken und die Fähigkeit, ein Experiment so aufzusetzen, dass das Ergebnis reproduzierbar ist. Am weitesten geht es in Richtung Betrieb: Ein MLOps Engineer schreibt Python als Werkzeugsprache für Automatisierung, und dort werden Umgebungen, Tests und Paketierung vom Nebenthema zum Kern.
Wenn du noch nicht weißt, welche Richtung dich interessiert, lohnt der Umweg über die Ratgeber zu Kenntnissen und Werkzeugen, bevor du dich in eine Bibliothek vertiefst. Und wenn du bereits mit Sprachmodellen als Assistenz arbeitest, gilt das, was im Beitrag zu KI-Werkzeugen im Arbeitsalltag steht: Sie beschleunigen das Schreiben, nicht das Verstehen. Code, den du nicht erklären kannst, ist im Praktikum eine Belastung.
Zwei Wochen gezielt aufholen
Angenommen, die Zusage ist da und du hast zwei Wochen. So würde ich sie verteilen.
Tage 1 bis 3: Nimm einen echten, unaufgeräumten Datensatz - kein Übungsdatensatz, sondern etwas aus einem offenen Datenportal mit fehlenden Werten und uneinheitlicher Schreibweise. Lies ihn ein, bring ihn in Form, beantworte drei konkrete Fragen daran. Nichts modellieren.
Tage 4 bis 6: Denselben Datensatz, aber jetzt mit Gruppierungen, Verknüpfungen zweier Tabellen und Zeitreihen. Hier liegen die Handgriffe, die du täglich brauchen wirst.
Tage 7 und 8: Räume auf. Zieh den Code aus dem Notebook in Funktionen und Dateien, leg eine virtuelle Umgebung an, schreib die Abhängigkeiten fest, setz zwei Tests darauf.
Tage 9 und 10: Git. Repository anlegen, in kleinen Schritten festschreiben, einen Zweig bauen, absichtlich einen Konflikt erzeugen und ihn auflösen. Eine README schreiben, die erklärt, was das Projekt tut und wie man es startet.
Die restlichen Tage: Fehler üben. Bau absichtlich kaputte Fälle - falsches Trennzeichen, fehlende Spalte, falscher Datentyp - und lies die Tracebacks, bis dich keiner mehr überrascht.
Was in diesem Plan nicht vorkommt, ist ein Kurs über neuronale Netze. Der Grund steht ausführlicher im Beitrag zu den Voraussetzungen für ein KI-Praktikum: Die Modelle sind selten der Engpass. Der Engpass sind die Daten davor.
Kurz gefasst
Kannst du Daten einlesen, in Form bringen, gruppieren und auswerten, verstehst du Fehlermeldungen, und läuft dein Code morgen noch - dann reicht dein Python für ein KI-Praktikum. Alles Weitere lernst du dort schneller als vorher allein.
Bereit für den nächsten Schritt?
Setz dein Wissen direkt ein und finde einen freien KI-Praktikum in deiner Nähe – kostenlos und ohne Anmeldung.
KI-Praktika finden
