Iterables versus Iteratoren: das Protokoll hinter for-Schleifen

Worum es geht

Die Bibliotheksreferenz dokumentiert zwei Methoden. Ein Iterable stellt __iter__() bereit, das einen Iterator zurückgibt; ein Iterator stellt __next__() bereit, das das nächste Element zurückgibt oder StopIteration wirft, sowie sein eigenes __iter__(), das sich selbst zurückgibt. Eine for-Schleife ruft iter() einmal und next() wiederholt auf. Die Folge: Ein Container liefert bei jedem iter()-Aufruf einen frischen Iterator, während ein an eine zweite Schleife übergebener Iterator sich selbst zurückgibt und leer erscheint, weil er bereits erschöpft ist. Die Referenz ergänzt, dass __next__(), sobald es einmal StopIteration geworfen hat, dies weiterhin tun muss, und nennt Implementierungen, die das nicht tun, "kaputt". iter(callable, sentinel) baut einen Iterator, der eine Funktion aufruft, bis sie das Sentinel zurückgibt, und next(it, default) gibt einen Standardwert zurück, statt zu werfen.

Warum es wichtig ist

Funktionen, die "eine Sequenz" verlangen, akzeptieren oft jedes Iterable und brechen dann, wenn sie zweimal iterieren (len(), ein Validierungsdurchlauf gefolgt von einem Verarbeitungsdurchlauf, Mitgliedschaftstests). Zu wissen, welches der beiden man in der Hand hat und welches eine Signatur verspricht, beseitigt eine ganze Klasse von Bugs mit leeren Ergebnissen.

So wird es angewendet

• Parameter als Iterable[T] für einen einzelnen Durchlauf annotieren und als Sequence[T] oder Collection[T], wenn len, Indexierung oder mehrere Durchläufe nötig sind; im Zweifel einmal mit list(xs) an der Grenze materialisieren.
• __iter__ bei eigenen Containern als Generatorfunktion implementieren; jeder Aufruf liefert einen neuen, unabhängigen Iterator ohne handgeschriebene Iteratorklasse.
• Eine Iteratorklasse nur schreiben, wenn sie Zustand braucht, den ein Generator nicht ausdrücken kann (Peek, Rewind, externe Steuerung), und __iter__ self zurückgeben lassen.
• Feste Blockgrössen mit iter(partial(f.read, 4096), b"") lesen; die Dokumentation der eingebauten Funktionen zeigt dieses Block-Reader-Idiom.
• Ein erstes Element sicher mit next(it, None) holen; mit itertools.islice überspringen.
• Faule Eingaben vor erneuten Versuchen oder vor einer der Nutzung vorangehenden Validierung materialisieren; beides würde die Daten sonst verbrauchen.

Stolpersteine

isinstance(x, Iterable) sagt nichts über erneute Iterierbarkeit; ein Generator besteht diese Prüfung und erschöpft sich trotzdem. Offene Dateien sind Iteratoren über Zeilen: Ein zweites for line in f liefert ohne f.seek(0) nichts. map, filter, zip, enumerate und reversed geben Einweg-Iteratoren zurück, während range, dict-Views und andere Container erneut iterierbar bleiben. Seit PEP 479 wird eine aus einem Generatorkörper entweichende StopIteration zu einem RuntimeError, weshalb next()-Aufrufe innerhalb von Generatoren einen Standardwert oder ein try brauchen. Eine Klasse mit __getitem__, die ab 0 beginnende Ganzzahlen akzeptiert, ist über das ältere Sequenzprotokoll iterierbar, selbst ohne __iter__.