@snafu: Naja, das führt aber auch dazu das man Bibliotheken schwerer versteht, die Sachen benutzen, die man selber nicht benutzt. Die Landschaft zersplittert, weil verschiedene Teilmengen von Programmierern verschiedene Teilmengen der Sprache verwenden. ``async``, „pattern matching“, Typannotationen, der Walross-Operator. Obwohl letzterer ja eigentlich noch am harmlosesten ist, hat der in der Community echt übel gespalten und ja letztlich auch zum Rücktritt von Guido als BDFL geführt, weil ihm das im nachhinein zu viel Gegenwind war als er den ohne Konsens durchgedrückt hatte.
Früher (wo natürlich alles besser war, selbst die Zukunft
) war das Kriterium für ein neues Sprachmittel in Python mal, dass es einen nachgewiesenen, greifbaren Vorteil hat. Heute ist das eher so, hey andere Sprachen haben das, wir brauchen das auch unbedingt in Python, lass mal möglichst viel da reinbasteln.
Bei *Dateien* und ``try``/``finally`` würde ich sogar sagen — warum denn nicht? Das ist jetzt nicht wirklich ein Riesengewinn:
Code: Alles auswählen
with open(…) as file:
# …
do_something_with(file)
# …
# vs.
file = open(…)
try:
# …
do_something_with(file)
# …
finally:
file.close()
Wirklich wichtig ist das ``with`` IMHO erst wenn erstellen und aufräumen für mich als Programmierer komplexer werden als jeweils ein Aufruf einer Funktion/Methode und man sich das wiederholen von komplexeren Code sparen kann, beispielsweise in Kombination mit `contextlib.contextmanager`:
Code: Alles auswählen
@contextmanager
def spam(…):
# …
# Komplexeres aufsetzen von Eiern.
# …
eggs = Eggs(…)
# …
try:
yield eggs
finally:
# …
# Komplexeres aufräumen.
# …
if eggs.is_frobnicated():
eggs.unfrobnicate(…)
# …
eggs.vaporize()
with spam(23) as eggs:
do_something_with(eggs)
with spam(42) as easter_eggs:
do_something_with(easter_eggs)
Man könnte natürlich aufsetzen und aufräumen jeweils in eine eigene Funktion stecken, aber dann kann man im Aufräumteil nicht auf lokale Variablen vom Aufsetzteil zugreifen, oder müsste eine Klasse mit einer `__init__()` zum aufsetzen und nur einer einzigen Methode zum aufräumen schreiben. Das riecht ja immer ein bisschen komisch nach Klasse die eigentlich eine Funktion sein sollte/wollte.
) war das Kriterium für ein neues Sprachmittel in Python mal, dass es einen nachgewiesenen, greifbaren Vorteil hat. Heute ist das eher so, hey andere Sprachen haben das, wir brauchen das auch unbedingt in Python, lass mal möglichst viel da reinbasteln.