Leonidas, du zitierst die Doku der älteren Versionen 2.2 und 2.3. Offenbar hat man da noch geglaubt, dass file() open() ablösen wird. Davon ist in neueren Versionen der Doku, wie du an meinen Zitaten gesehen hast, nicht mehr die Rede.
Im Gegenteil, es ist sogar eher wieder eine gegenläufige Tendenz zu spüren:
Python 2.4.4 sagt noch: "Both spellings are equivalent. The intent is for open() to continue to be preferred for use as a factory function which returns a new file object."
Das würde ich so übersetzen, dass open() und file() prinzipiell gleichwertig sind. open() ist zwar eher als Factory-Funktion für file Objekte gedacht, aber das ist hier noch mehr eine Entscheidungshilfe als eine wirkliche Empfehlung.
Python 2.5 geht aber noch einen Schritt weiter und sagt: "When opening a file, it's preferable to use open() instead of invoking this constructor directly."
Das würde ich nun so interpretieren, dass es in Python 2.5 sogar deutlich empfohlen ist, open() zum Öffnen von Dateien zu verwenden.
Ich halte mich im Zweifel an die neuen Versionen der Dokumentation. Python 2.2 und 2.3 sind heute nicht mehr aktuell. Wenn ich ehrlich bin, muss ich sogar zugeben, dass ich - von Java kommend - am Anfang auch eher zu file() tendiert habe. Da ich aber mit Python 2.4 angefangen habe, bin ich auf die schon zitierten Stellen in der Dokumentation gestoßen und verwende seit dem open(), was mir heute auch logischer als file() erscheint.
Gruß
lunar
file() vs. open()
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Ich weiß, die seltsame Kursänderung ist mir auch aufgefallen, daher habe ich in der alten Dokumentation gegraben um das belegen zu können.
Nichts desto trotz wurde für keine Alternative jemals eine Deprecation ausgesprochen und daher denke ich, dass sich das Verhalten von file() und open() in Python 2.x nie ändern wird.
Was ich jetzt ausgegraben habe, sind ein paar Posts in python-dev: file() vs open(), round 7 welches der Follow-Up-Thread zu file() or open()? ist. Muss ich mir mal durchlesen, dann können wir uns weiterstreiten
Nichts desto trotz wurde für keine Alternative jemals eine Deprecation ausgesprochen und daher denke ich, dass sich das Verhalten von file() und open() in Python 2.x nie ändern wird.
Was ich jetzt ausgegraben habe, sind ein paar Posts in python-dev: file() vs open(), round 7 welches der Follow-Up-Thread zu file() or open()? ist. Muss ich mir mal durchlesen, dann können wir uns weiterstreiten
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Ich weiß auch nicht aber ist vielleicht für File sowas geplant?
Das wäre für mich ein Argument mehr ``file`` zu nutzen.Leonidas hat geschrieben:Da hast du recht. Wenn ich es mir so überlege, könnte das FIle-Objekt so eine Funktionalität durchaus auch bereitstellen. Das wäre logisch: über das FIle-Objekt bekommt man den Namen, die Attribute und den Inhalt einer Datei.lunar hat geschrieben:Klar, aber bei file() denke ich nicht sofort daran, dass man eine Datei zum Lesen oder Schreiben öffnen will. Ich halte das eher für eine abstrakte Betrachtung einer Datei; also etwas, bei dem man Namen, Erweiterung oder Pfad abfragen kann...
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
BlackJack meinte, dass es im Gespräch für Python 3k war, aber so wie ich es sehe hat Guido hier gemeint, dass es für CPython theoretisch möglich wäre. Ist alledings mit einer Menge Komplikationenen verbunden.sape hat geschrieben:Ich weiß auch nicht aber ist vielleicht für File sowas geplant?
Interessanterweise ist dieser Thread bisher quasi eine Übsersetzung des Python-Dev Threads "file() or open()". Die Argumente sind ziemlich ähnlich, nur die Sprache ist anders
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Das mit ``open()``, dass geplant ist das es andere Sachen wie URLs öffnen kann, habe ich ja schon hier im Thread mitgekriegt das es für Python 3K geplant ist. Mich würde aber interessieren, ob vielleicht irgendwann das ``file`` Objekt um solche Sachen erweitert werden die lunar angepsrochen hat. Das würde ich persönlich auch sehr logisch finden Dan bräuchte man z.B. nicht mehr ``os.stat`` sondern hat dann alles in der Instanz von ``file``.
lg
sape
P.S:
lg
sape
P.S:
Was für ein glück, dann muss ich mir das nicht übersetzen *ggInteressanterweise ist dieser Thread bisher quasi eine Übsersetzung des Python-Dev Threads "file() or open()". Die Argumente sind ziemlich ähnlich, nur die Sprache ist anders
Eine Zeit lang habe ich auch versucht, file() statt open() zu verwenden, zumal file() ja auch die eigentliche Funktion ist und open() nur der Alias (im weiteren Sinne).
Welcher der beiden Namen besser zutrifft, hängt letztlich von der Betrachtungsweise ab, beides mehr oder weniger von Fall zu Fall.
Letztlich ist aber open ein Verb und damit definitiv PEP8-konformer.
Für open() spricht zudem POLS (Principle of Least Surprise), d.h. dass es in eingen anderen Sprachen (Perl fällt mir ein) auch so heißt.
Welcher der beiden Namen besser zutrifft, hängt letztlich von der Betrachtungsweise ab, beides mehr oder weniger von Fall zu Fall.
Letztlich ist aber open ein Verb und damit definitiv PEP8-konformer.
Für open() spricht zudem POLS (Principle of Least Surprise), d.h. dass es in eingen anderen Sprachen (Perl fällt mir ein) auch so heißt.
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Das würde auch für chomp() gelten.. klingt sogar wie ein Verb. Will ich aber trotzdem nicht in Python sehenY0Gi hat geschrieben:Für open() spricht zudem POLS (Principle of Least Surprise), d.h. dass es in eingen anderen Sprachen (Perl fällt mir ein) auch so heißt.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Eben. Wir streiten uns hier um den Sinn und Unsinn der Namen open() und file(). Mein Argument ist, dass übernehmen von Namen aus anderen Programmiersprachen nicht immer eine gute Idee ist. Die Ruby-Leute haben genau dazu einen Thread.Y0Gi hat geschrieben:Wozu chop() und chomp(), wenn es "".[l/r]strip([chars]) gibt?
Übrigens, in Rubys Stdlib ist es durchaus so, dass eine Funktion mehrere Namen hat und die Leute die selbe Funktion mit verschiedenen Namen nutzen. Ist in Python quasi undenkbar, wie man schon an dieser Diskussion sieht
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Heißt es nicht irgendwo "There should be only one way to do it"?Leonidas hat geschrieben:Eben. Wir streiten uns hier um den Sinn und Unsinn der Namen open() und file(). Mein Argument ist, dass übernehmen von Namen aus anderen Programmiersprachen nicht immer eine gute Idee ist. Die Ruby-Leute haben genau dazu einen Thread.Y0Gi hat geschrieben:Wozu chop() und chomp(), wenn es "".[l/r]strip([chars]) gibt?
Ist in Python quasi undenkbar, wie man schon an dieser Diskussion sieht
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Ja, im Zen of Python.lunar hat geschrieben:Heißt es nicht irgendwo "There should be only one way to do it"?
Der Zen ist irgendwie ein Meisterstück.Zen of Python hat geschrieben:There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Danke, ich hatte den Namen vergessen. (Frag mich nicht warum, aber irgendwie war ich die ganze Zeit auf "python mantra" fixiert )Leonidas hat geschrieben:Ja, im Zen of Python.lunar hat geschrieben:Heißt es nicht irgendwo "There should be only one way to do it"?
Ist das jetzt Ernst oder Sarkasmus?Leonidas hat geschrieben:Der Zen ist irgendwie ein Meisterstück.Zen of Python hat geschrieben:There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Das ist durchaus ernst - je länger man Python kennt, desto mehr versteht man die Botschaft des Zens. Es ist die Philosophie von Python, gebannt ein einige Zeilen lyrischen Text. Originell, witzig, hilfreich.lunar hat geschrieben:Ist das jetzt Ernst oder Sarkasmus?
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Sehr gut, so sehe ich das nämlich auch Andernfalls hätten wir nämlich gleich die nächste Diskussion anfangen könnenLeonidas hat geschrieben:Das ist durchaus ernst - je länger man Python kennt, desto mehr versteht man die Botschaft des Zens. Es ist die Philosophie von Python, gebannt ein einige Zeilen lyrischen Text. Originell, witzig, hilfreich.lunar hat geschrieben:Ist das jetzt Ernst oder Sarkasmus?
Dann muss ich mir also nicht komisch vorkommen, dass ich es ausgedruckt und neben den Monitor an die Wand gehängt habe.
Der Geist, der in diesen Zeilen steckt ist IMHO letztendlich nicht auf Python beschränkt sondern recht universell.
Der Geist, der in diesen Zeilen steckt ist IMHO letztendlich nicht auf Python beschränkt sondern recht universell.
Das erzähl' mal einem Perl-GuruBlackJack hat geschrieben:Der Geist, der in diesen Zeilen steckt ist IMHO letztendlich nicht auf Python beschränkt sondern recht universell.
Leute wir sind hier immer noch am Programmieren und Python ist keine Religon sondern ein Programmierer-Werkzeug Zugegeben, für mich momentan das beste Davon abgesehen (von dem ganzen Pseudo- Religions-gedöns-blubb den einigen reininterpretieren) ist Pythons Zen schon recht gut und so einfach das jeder darauf kommen hätte können (gerade die Einfachheit und Schlüssigkeit macht es so Sympatisch)
Mir gefällt ja sehr gut -> "3. Einfach ist besser als komplex." in Verbindung mit "4. Komplex ist besser als kompliziert."
Gerade die Sätze lassen viel Freiraum, weil ein jeder weiß, das Problemlösungen sich nicht immer Einfach formulieren lassen, sonder auch oft Komplex sein müssen, (weil es eben nicht anders geht) aber niemals Kompiliert sein müssen! So nach dem Moto "17. Wenn die Implementierung schwer zu erklären ist, ist sie keine gute Idee."
lg
Mir gefällt ja sehr gut -> "3. Einfach ist besser als komplex." in Verbindung mit "4. Komplex ist besser als kompliziert."
Gerade die Sätze lassen viel Freiraum, weil ein jeder weiß, das Problemlösungen sich nicht immer Einfach formulieren lassen, sonder auch oft Komplex sein müssen, (weil es eben nicht anders geht) aber niemals Kompiliert sein müssen! So nach dem Moto "17. Wenn die Implementierung schwer zu erklären ist, ist sie keine gute Idee."
lg