LU07.L05 - Schleife zur Pipeline

# 1 umformen
namen = [e["name"].capitalize() for e in eintraege]
# ['Meier', 'Keller', 'Suter', 'Wyss']
 
# 2 filtern und umformen
gute = [e["name"] for e in eintraege if e["aktiv"] and e["punkte"] >= 50]
# ['suter', 'wyss']
 
# 3 zusammenfassen
total = sum(e["punkte"] for e in eintraege if e["aktiv"])
# 185
 
# 4 dict aufbauen
punkte_nach_name = {e["name"]: e["punkte"] for e in eintraege}
# {'meier': 42, 'keller': 17, 'suter': 88, 'wyss': 55}

Diese Schleife tut drei Dinge, die gegen eine Pipeline sprechen:

• Seiteneffekt: protokollieren(e) muss für jeden Eintrag bis zum Treffer ausgeführt werden. Eine Comprehension, die nur wegen eines Seiteneffekts läuft, ist ein Missbrauch.
• Vorzeitiger Abbruch: break hat in einer Comprehension keine Entsprechung.
• Zwei Ergebnisse gleichzeitig: protokollierte Einträge und der gefundene Name.

Nur wenn das Protokollieren wegfällt, ist die deklarative Fassung sinnvoll und sogar besser, weil next beim ersten Treffer aufhört:

gefunden = next((e["name"] for e in eintraege if e["punkte"] > 80), None)

from functools import reduce
 
total = reduce(lambda a, e: a + e["punkte"], [e for e in eintraege if e["aktiv"]], 0)

Beurteilung: Alle drei Fassungen liefern 185. Für das Projekt ist sum(…) die richtige Wahl - sie ist am kürzesten und für jede Leserin sofort verständlich. reduce lohnt sich erst, wenn die Verknüpfung keine eingebaute Funktion hat, etwa beim Zusammenfassen von Dictionaries oder bei einer eigenen Verrechnungslogik. Genau diese Begründung, nicht die Fassung selbst, ist der Kompetenznachweis.

assert namen == alt_namen
assert gute == alt_gute
assert total == alt_total
assert punkte_nach_name == alt_dict

Ohne diese vier Zeilen ist der Umbau nicht belegt.

© Kevin Maurizi