Glossar - Einführung in Python

Diese Seite sammelt die Begriffe, die im Skript benutzt werden und sich nicht aus dem Java-Vorwissen erschließen. Jeder Eintrag ist ein bis zwei Sätze lang und verweist auf die Stelle, an der der Begriff ausführlich vorkommt. Die Seite ist zum Nachschlagen gedacht, nicht zum Lesen am Stück.

Sprache und Stil¶

Dunder (Double Underscore): Methoden der Form __name__, die Python bei bestimmten Operationen selbst aufruft: __init__ beim Erzeugen, __add__ bei +, __iter__ in einer for-Schleife. Sie sind kein privater Implementierungskram, sondern die eigentliche Schnittstelle zum Sprachkern — siehe Operatoren überladen.
Pythonic: Bezeichnet Code, der die vorhandenen Sprachmittel benutzt, statt Idiome aus anderen Sprachen nachzubauen: eine Comprehension statt einer Zählschleife mit append, ein Kontextmanager statt try/finally mit close(), Entpacken statt Indexzugriffen. Der Maßstab ist nicht Kürze, sondern Lesbarkeit für jemanden, der Python kennt.
EAFP / LBYL: “Easier to Ask for Forgiveness than Permission” gegen “Look Before You Leap”. Python bevorzugt EAFP: Man führt die Operation aus und fängt die Exception, statt vorher alle Bedingungen abzufragen. Das vermeidet Race Conditions zwischen Prüfung und Zugriff — siehe Try With.
Duck Typing: Ein Argument wird nicht auf seinen Typ geprüft, sondern darauf, ob es die benötigten Methoden hat. Siehe Duck Typing; die aufgeschriebene Variante davon ist ein Protocol.
Monkey Patching: Das nachträgliche Ersetzen von Attributen oder Methoden eines fremden Objekts oder Moduls zur Laufzeit. In Tests ein legitimes Werkzeug (monkeypatch), im Produktivcode ein Wartungsproblem — siehe Duck Typing.
MRO (Method Resolution Order): Die Reihenfolge, in der Python bei Mehrfachvererbung nach einer Methode sucht. Sie ergibt sich aus der Reihenfolge der Basisklassen und ist mit Klasse.__mro__ einsehbar — siehe Mehrfachvererbung.

Bausteine¶

Comprehension: Kompakte Schreibweise, aus einem Iterable eine Liste, ein Set oder ein Dict zu erzeugen: [f(x) for x in xs if p(x)]. Mit runden Klammern entsteht stattdessen ein Generator.
Iterable / Iterator / Generator: Ein Iterable kann __iter__ und liefert damit einen Iterator; ein Iterator kann __next__ und meldet das Ende mit StopIteration. Ein Generator ist der vom Compiler erzeugte Iterator zu einer Funktion mit yield oder zu einem Generator-Ausdruck. Siehe Iterable und Iterator.
Closure: Eine innere Funktion, die eine Variable aus der umgebenden Funktion festhält, auch nachdem diese zurückgekehrt ist. Die leichtgewichtige Alternative zu einem Objekt, das denselben Zustand als Attribut hält — siehe Scope und Closures.
Dekorator: Eine Funktion, die eine Funktion (oder Klasse) nimmt und eine ersetzte zurückgibt; @name ist nur Schreibweise für f = name(f). Anders als eine Java-Annotation sind Dekoratoren ausführbarer Code, nicht Metadaten — siehe Dekoratoren.
Kontextmanager: Ein Objekt mit __enter__/__exit__, das in einem with-Block Ressourcen zuverlässig wieder freigibt — siehe Try With.
Sentinel: Ein eindeutiges Wächter-Objekt, das “kein Wert übergeben” bedeutet, wenn None bereits ein gültiger Wert ist — siehe Sentinel values.
Dataclass: Eine Klasse, deren __init__, __repr__ und __eq__ aus den annotierten Feldern erzeugt werden; das Python-Gegenstück zum record — siehe Dataclasses.
Enum: Eine feste Menge benannter Werte als eigener Typ, statt Strings oder Zahlen als magische Konstanten — siehe Enums.
Protocol: Ein strukturell geprüftes Interface: Wer die Methoden hat, erfüllt es, ohne zu erben. Erlaubt es, fremden Code nachträglich zu typisieren — siehe Protocols.
ABC (Abstract Base Class): Ein nominal geprüftes Interface: Wer es erfüllen will, muss erben und alle @abstractmethod implementieren — siehe ABCs.
f-String: String-Literal mit vorangestelltem f, in dem {ausdruck} ausgewertet und formatiert wird — siehe f-Strings.

Nebenläufigkeit¶

Coroutine: Eine mit async def definierte Funktion. Ihr Aufruf führt noch nichts aus, sondern erzeugt ein Objekt, das an await-Stellen die Kontrolle abgeben und später dort weitermachen kann — siehe Asyncio.
Event Loop: Die Schleife, die lauffähige Coroutinen auswählt und ausführt. Nebenläufigkeit entsteht hier durch freiwillige Abgabe an await-Stellen (kooperativ), nicht durch Verdrängung wie bei Threads — siehe Asyncio.
GIL (Global Interpreter Lock): Die Sperre, die in CPython sicherstellt, dass immer nur ein Thread Python-Bytecode ausführt. Threads helfen deshalb bei I/O, aber klassisch nicht bei rechenintensivem Code; seit 3.13 gibt es experimentelle Builds ohne GIL (Free Threading) — siehe Asyncio.
Race Condition: Ein Fehler, dessen Auftreten davon abhängt, in welcher Reihenfolge nebenläufige Abläufe an gemeinsame Daten kommen. Typisch reproduzierbar erst unter Last — siehe Asyncio.

Werkzeuge und Ökosystem¶

PEP (Python Enhancement Proposal): Nummerierte Dokumente, in denen Änderungen an Sprache und Standardbibliothek vorgeschlagen, diskutiert und beschlossen werden. PEP 8 (Stil) und PEP 20 (Zen of Python) sind die bekanntesten; ein PEP mit Status “Draft” ist kein Versprechen — siehe Haben wir noch PEPs?.
venv (Virtuelle Umgebung): Ein Ordner mit eigenem Interpreter-Link und eigenem site-packages, damit Projekte unterschiedliche Paketversionen benutzen können, ohne sich zu stören — siehe Packaging.
Wheel: Das Binärformat für Python-Pakete (.whl): ein ZIP-Archiv, das beim Installieren nur entpackt statt gebaut wird. Für kompilierte Pakete gibt es je ein Wheel pro Plattform und Python-Version — siehe Packaging.
Lockfile: Eine Datei (uv.lock), die für jedes Paket die exakt aufgelöste Version festhält, damit eine Installation anderswo dasselbe Ergebnis liefert. Gehört ins Repository — siehe Packaging.
Linter / Formatter / Type Checker: Drei verschiedene Werkzeuge: Der Linter (ruff, pylint) sucht verdächtige Muster, der Formatter (ruff format, black) stellt Layout her, ohne die Semantik zu ändern, der Type Checker (mypy) prüft die Type Hints gegen den Code. Keiner ersetzt Tests — siehe Code-Qualität.
Type Hint: Eine Typannotation wie def f(x: int) -> str. Sie wird zur Laufzeit nicht geprüft; ihren Nutzen entfaltet sie in Type Checker, IDE und Dokumentation — siehe Type Hints.
LSP (Language Server Protocol): Das Protokoll, über das ein Editor Vervollständigung, Sprungmarken und Fehler von einem separaten Sprachserver bezieht. Deshalb kann derselbe Python-Server VS Code, Neovim und Emacs bedienen — siehe IDEs.
REPL: “Read-Eval-Print-Loop”, die interaktive Python-Sitzung. Der schnellste Weg, eine Annahme über eine Bibliothek zu prüfen.

Testen und Verifikation¶

Unit Test: Ein Test, der eine einzelne Einheit isoliert und ohne Netz, Datenbank oder Uhr prüft — siehe Testing.
TDD (Test-Driven Development): Die Arbeitsweise, den Test vor der Implementierung zu schreiben und ihn zuerst fehlschlagen zu sehen: rot, grün, refaktorisieren — siehe Testing.
Fixture: Eine Funktion, die einem Test seine Vorbedingungen bereitstellt (Verzeichnis, Datenbank, Objekt) und danach aufräumt. In pytest ein Parameter, dessen Name auf eine @pytest.fixture verweist — siehe Testing.
Mock: Ein Platzhalterobjekt, das eine echte Abhängigkeit ersetzt und aufzeichnet, wie es benutzt wurde. Macht Tests unabhängig von fremden Systemen und zugleich abhängig von der Annahme, dass der Platzhalter sich wie das Original verhält — siehe Testing.
Coverage (Testabdeckung): Der Anteil der Zeilen oder Zweige, die beim Testlauf ausgeführt wurden. Eine Untergrenze, kein Qualitätsmaß: Ausgeführt heißt nicht geprüft — siehe Testing.
Property-Based Testing: Statt einzelner Beispiele formuliert man eine Eigenschaft, die für alle Eingaben gelten soll, und lässt das Werkzeug (hypothesis) Eingaben erzeugen und Gegenbeispiele minimieren — siehe Testing.
Mutation Testing: Das Werkzeug verändert den Produktivcode gezielt (aus < wird <=) und prüft, ob ein Test das merkt. Überlebende Mutationen zeigen Tests, die nichts prüfen — siehe Testing.
Contract (Design by Contract): Vor- und Nachbedingungen sowie Invarianten, die als ausführbare Zusicherungen am Code stehen und bei jedem Aufruf geprüft werden — siehe Design by Contract.
Symbolic Execution: Ein Analyseverfahren, das den Code nicht mit konkreten Werten, sondern mit Symbolen durchläuft und einen Solver fragen lässt, welche Eingaben eine Bedingung verletzen — siehe Testing.
Doctest: Beispiele im Docstring, die aussehen wie eine REPL-Sitzung und als Test ausgeführt werden können. Hält Dokumentation und Verhalten zusammen — siehe Testing.
Golden Master / Charakterisierungstest: Ein Test, der nicht die richtige, sondern die bisherige Ausgabe festhält. Das Mittel der Wahl, bevor man fremden Code ohne Testsuite verändert.

Profiling¶

Profiler: Ein Werkzeug, das misst, wo die Laufzeit (oder der Speicher) eines Programms tatsächlich hingeht. Die Vorhersage aus dem Kopf liegt regelmäßig daneben — siehe Profiling.
Deterministisch vs. Sampling: Ein deterministischer Profiler (cProfile) verzeichnet jeden Aufruf und verfälscht dadurch kurze Funktionen; ein Sampling-Profiler (py-spy) sieht in festen Abständen nach und ist billig genug für laufende Produktivprozesse — siehe Profiling.
Flamegraph: Die übliche Darstellung von Profiling-Daten: Breite entspricht verbrauchter Zeit, Stapelung entspricht der Aufrufkette — siehe Profiling.

KI-gestützte Entwicklung¶

LLM (Large Language Model): Ein Sprachmodell, das Text (und damit auch Code) fortsetzt. Es hat keinen Zugriff auf die Wahrheit, sondern auf die Wahrscheinlichkeit von Fortsetzungen — die Prüfung bleibt beim Menschen oder bei Werkzeugen.
Kontextfenster: Die begrenzte Menge an Text, die ein Modell in einem Schritt berücksichtigen kann. Die Auswahl dessen, was hineinkommt, beeinflusst das Ergebnis stärker als die Formulierung des Prompts.
Vibe Coding: Von Andrej Karpathy geprägter Begriff für die Arbeitsweise, generierten Code zu übernehmen, ohne ihn zu lesen. Tragfähig für Wegwerfprojekte, nicht für Code, den jemand später warten muss — siehe IDEs.
Agentic Coding: Ein LLM in einer Schleife mit Werkzeugen: Es liest Dateien, führt Kommandos aus, liest Fehlermeldungen und korrigiert, bis Linter und Tests durchlaufen. Deshalb sind automatische Prüfkriterien hier doppelt wertvoll — siehe IDEs.
Tool Call: Ein strukturierter Abschnitt im Modell-Output, den das umgebende Programm als Aufruf eines externen Werkzeugs interpretiert und dessen Ergebnis es zurückspeist. Der Mechanismus hinter allen Agenten.
Halluzination: Eine erfundene, aber plausibel formulierte Angabe — etwa eine Methode, die es in der Bibliothek nicht gibt. Der Grund, warum generierter Code ausgeführt und nicht nur gelesen werden sollte.