With-Statement

[birkenfeld]

Dass neue Features Änderungen mit sich bringen, und Programmierer sich auf sie einstellen müssen, ist klar. Nur gilt das nicht nur für Features, die mit einem Future-Import aktiviert werden müssen. Es gab zum Beispiel keinen Future-Import für dein anderes angeführtes Beispiel, die Dekoratoren -- die waren direkt in 2.4 eingeführt und verwendbar.

Ganz allgemein gesprochen: Ein Future-Import sagt *nichts*, aber auch *gar nichts* über die Stabilität oder die Komplexität eines neuen Features aus, sondern lediglich, dass es nicht zu 100% backwards-compatible ist (bei "with" eben wegen dem neuen Keyword). Deshalb verstehe ich es nicht, an diesem Import die "Verwendbarkeit" festzumachen.

Und warum "with" mit einem Lock komplizierter ist als acquire, try-finally und release, musst du mir auch erklären.

Mein Knie brauche ich übrigens noch.

[Leonidas]

Da jetzt das neue Statement von vielen Leuten verwendet wird, ist vielleicht noch etwas aufgefallen was man besser machen könnte -- zumindest im Hintergrund. Das muss aber nicht sein.
Wie auch immer. In der nächsten Version ist der Future-Import nicht mehr nötig. Die Programmierer hatten genug Zeit, alte Programme zu bereinigen und zu testen. Dem Einsatz des neuen Statements steht nichts mehr im Wege.

Es gibt aber auch programmierer, die sich weitern die zu nutzen und dann eben die Erfahrungen in Python 2.6 machen werden müssen. Oder es komplett ignorieren, denn dass ``with`` ein Keyword ist, werden die wenigsten merken.

Hinter "with" steht ja nicht nur dieses eine Wort. Dahinter steht die jetzt neu in Python eingebaute Möglichkeit, eigene Objekte so zu erweitern, dass diese auch mit "with" verwendet werden können. Und diese neuen Möglichkeiten enden erfahrungsgemäß in komplizierterem Python-Code.

Nein. Um etwa Objekte, die ``close()`` implementieren sauber anzusprechen reicht ein einziger Aufruf von ``contextlib.closing()``.

Außerdem wird der Code einfacher zu lesen und generell stabiler. So ist dieser Ausschnitt:

Code: Alles auswählen

with open('/etc/passwd', 'r') as f:
    for line in f:
        print line

äquivalent zu diesen:

Code: Alles auswählen

f = open('/etc/passwd', 'r')
try:
    for line in f:
        print line
finally:
    f.close()

Wer von euch öffnet Dateien auf diese Weise, die Sichergeht, dass die Datei auch bei fehlern geschlossen wird. Wer von euch vergisst sowas gerne?

Python-Programme, die Dekoratoren definieren, sind ja auch komplizierter geworden. Nur fällt das denen, die so etwas fabrizieren, nicht mehr auf. Und so etwas gefällt nicht unbedingt jedem einfachen Praktiker oder Hobby-Programmierer. Erst recht nicht, wenn man das Gleiche erreicht, indem man ein wenig anders programmiert.

Im Gegensatz zu Dekoratoren sind Context-Manager aber wesentlich einfacher zu schreiben, ich war da selbst erstaunt, dass das Interface so komfortabel war. Es sind im großen und ganzen ja nur Codeblöcke mit Pre- und Postconditions, so etwas kann man mit Funktionen und Dekoratoren nachbauen, wenn man masochistisch genug ist.

Das kann man etwas mit Unicode vergleichen: die Programme zu verstehen wird etwas komplizierter (aber nicht sonderlich, denn wie gesagt - Context Manager sind einfach zu verstehen) dafür macht es das Programm einfacher. Ich finde es super, dass Python 3.0 Unicode durchweg verwendet, denn dann fallen viele Möglichkeiten weg, an zufälligen Stellen wegen Umlauten zu crashen. Mit Context Managern falen Probleme mit Finalizing weg, da dass dann automatisch geschieht.



EDIT by Gerold: Hallo Leonidas! Ich hatte, statt auf den Zitat-Knopf, auf den EDIT-Knopf gedrückt und so deinen Beitrag überschrieben. Ich hatte den Beitrag zum Glück noch im Firefox-Cache und konnte ihn rekonstruieren. -- Sorry!

[gerold]

Im Gegensatz zu Dekoratoren sind Context-Manager aber wesentlich einfacher zu schreiben, ich war da selbst erstaunt, dass das Interface so komfortabel war.

Hallo Leonidas!

Das ist mal ein Wort! Ich freue mich, wenn sich mein Vorurteil in dieser Sache nicht bestätigt.

@All: Ich habe doch nicht behauptet, dass "with" schlecht ist!
Ich habe nur behauptet, dass ICH mir "with" (aus den verschiedensten Gründen) erst ein wenig später rein ziehen werde. Und ICH es erst empfehlen kann, wenn ich mich damit befasst habe. Das hindert euch doch nicht daran, "with" zu verwenden und zu empfehlen.

Wenn ich ein Codebeispiel ohne "with" schreibe, dann genügt es ja, wenn irgendjemand von euch dem "with" am Herzen liegt, in einem weiteren Beitrag dazu schreibt, dass man ab Python 2.5, durch die Einführung des "with"-Schlüsselwortes den Code auch anders schreiben kann.

Aber nein, stattdessen wird großes Trara darum gemacht, weil ich keine Zeit dafür habe mich damit zu befassen und es in meinen Codebeispielen noch nicht verwende. Vielen, vielen Dank!

[birkenfeld]

Sorry, aber du reagierst hier, als wenn wir dich extra persönlich beleidigen wollten. Dem ist nicht so. Hättest du auch anfänglich nur sowas geschrieben:

weil ich keine Zeit dafür habe mich damit zu befassen und es in meinen Codebeispielen noch nicht verwende

hätte es sicher auch keinen so langen Thread gegeben.

Statt dessen hast du behauptet, Features aus Future-Imports wären in einer Art Beta-Phase und hätten potentiell Kinderkrankheiten. Das haben wir richtiggestellt.

[gerold]

Statt dessen hast du behauptet, Features aus Future-Imports wären in einer Art Beta-Phase und hätten potentiell Kinderkrankheiten.

Dass man es so auffassen könnte, stimmt auch wieder. Ich wollte in den vorherigen Beiträgen nur klar stellen, warum ich mir nicht jetzt schon die Zeit nehme, mich um "with" zu kümmern.

[lunar]

*popcornwiedereinpack* ... und ich hatte mich schon so doll auf einen schönen Flamewar gefreut

[jens]

Hab mal [wiki]Tutorial/with[/wiki] erstellt