Das deutsche Python-Forum

sape hat geschrieben:Sorry, Kurz OT: `open()` vs. `file()`. Eigentlich egal oder?

Ja, haben beide die selben Parameter und liefern beide das selbe file-Objekt zurück. Die Doku bevorzugt zwar open(), ich finde aber file() definitiv aussagekräftiger.

Edit (Leonidas): Aus dem Thread Text aus Datei laden?? gesplittet.

Leonidas hat geschrieben:Die Doku bevorzugt zwar open(), ich finde aber file() definitiv aussagekräftiger.

Hi Leonidas!

Das sehe ich auch so.
``list()`` liefert mir eine Liste, ``dict()`` liefert mir ein Dictionary und ``file()`` liefert mir ein File-Objekt. Das ist für mich einfach "logischer" als die Aussage "``open()`` liefert dir ein File-Objekt".

lg
Gerold

gerold hat geschrieben:
Leonidas hat geschrieben:Die Doku bevorzugt zwar open(), ich finde aber file() definitiv aussagekräftiger.
Hi Leonidas!

Das sehe ich auch so.
``list()`` liefert mir eine Liste, ``dict()`` liefert mir ein Dictionary und ``file()`` liefert mir ein File-Objekt. Das ist für mich einfach "logischer" als die Aussage "``open()`` liefert dir ein File-Objekt".

Nur um mal ein bisschen Öl ins Feuer zu gießen

:
Ich finde open sinnvoller, immerhin öffnet man ja eine Datei.

Man öffnet aber auch einen Socket...

Joghurt hat geschrieben:Man öffnet aber auch einen Socket...

Aber wohl kaum durch die Übergabe eines Dateinamens, oder?

lunar hat geschrieben:Nur um mal ein bisschen Öl ins Feuer zu gießen

lunar hat geschrieben:
Joghurt hat geschrieben:Man öffnet aber auch einen Socket...
Aber wohl kaum durch die Übergabe eines Dateinamens, oder?

Unix-Sockets?
Nein, ganz im ernst, aber open() könnte dem namen nach alles mögliciche öffnen, zum Besipiel könnte ich mir vorstellen, dass wenn ich open('http://www.python-forum.de/index.html') angebe, es was zurückliefert, ebenso open('127.0.0.1:2501'). Tut es aber irgendwie nicht. Bei file() find ich es deutlicher, dass ich nun, eben ein File haben will. In der urllib heißt es auch urlopen() und nicht einfach lapidar open().

Ist open() nicht als "deprecated" eingestuft?

Leonidas hat geschrieben:Bei file() find ich es deutlicher, dass ich nun, eben ein File haben will. In der urllib heißt es auch urlopen() und nicht einfach lapidar open().

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...

Möglich, dass sich da noch die Java- und C# Erfahrung niederschlägt:
http://java.sun.com/j2se/1.5.0/docs/api ... /File.html
http://www.go-mono.com/docs/index.aspx? ... em.IO.File

Ich würde sagen, dass wir einigen uns auf fileopen() als optimale Lösung

Bis es das gibt, verwendet jeder, was er lieber mag...

Stephan hat geschrieben:Ist open() nicht als "deprecated" eingestuft?

Eigentlich hatte ich auch so etwas im Kopf (wenn nich deprecated dann encouraged to use file()), aber nachdem ich noch mal in der Dokumentation zu file() und zu open() zur sicherheit nachgeschaut habe, steht dort etwas anderes. So etwas wie lunar eben meint, was mich aber nicht überzeugt. Andererseits ist es letztendlich egal was man nutzt, der Effekt ist der gleiche, und keine der Beiden Funktionen wird in nächster Zeit abgeschafft.

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...

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:Möglich, dass sich da noch die Java- und C# Erfahrung niederschlägt:
http://java.sun.com/j2se/1.5.0/docs/api ... /File.html

An sich finde ich das gar nicht mal blöd (Ausnahmsweise mal). Lediglich die Funktionalität zum Auslesen des Inhalts fehlt mir.

lunar hat geschrieben:Ich würde sagen, dass wir einigen uns auf fileopen() als optimale Lösung

Ok - oder die Übernahme von java.io.FIle und dem Hinzufügen von Lese- und Schreibfunktionalität. Andererseits.. warum heißt es urllib.urlopen() wenn der PEP8 doch eher von url_open() sprechen würde.
Für Python 3k wünsch' ich mir etwas mehr Konsistenz

Leonidas hat geschrieben:
lunar hat geschrieben:
Joghurt hat geschrieben:Man öffnet aber auch einen Socket...
Aber wohl kaum durch die Übergabe eines Dateinamens, oder?
Unix-Sockets?

Auch die nicht. Oder haben die Namen?

Nein, ganz im ernst, aber open() könnte dem namen nach alles mögliciche öffnen, zum Besipiel könnte ich mir vorstellen, dass wenn ich open('http://www.python-forum.de/index.html') angebe, es was zurückliefert, ebenso open('127.0.0.1:2501'). Tut es aber irgendwie nicht.

Noch nicht. So etwas war durchaus schon im Gespräch für Python 3K.

Leonidas hat geschrieben:file() und zu open() [...], und keine der Beiden Funktionen wird in nächster Zeit abgeschafft.

file ist keine Funktion. Es ist der Konstruktor des File-Objekts. Open ist eine Funktion, die das entsprechende File-objekt zurückgibt, oder besser gesagt: ein Alias für den file-Konstruktor.

Das mit dem Alias stimmt ab Python 2.5 nicht mehr. In 2.4:

Code: Alles auswählen

In [4]: file
Out[4]: <type 'file'>

In [5]: open
Out[5]: <type 'file'>

In [6]: file is open
Out[6]: True

Die letzte Zeile liest sich irgendwie witzig

Und in 2.5:

Code: Alles auswählen

>>> file
<type 'file'>
>>> open
<built-in function open>
>>> file is open
False

Joghurt hat geschrieben:
Leonidas hat geschrieben:file() und zu open() [...], und keine der Beiden Funktionen wird in nächster Zeit abgeschafft.
file ist keine Funktion. Es ist der Konstruktor des File-Objekts. Open ist eine Funktion, die das entsprechende File-objekt zurückgibt, oder besser gesagt: ein Alias für den file-Konstruktor.

Also ich finde diesen Hinweis trotz seiner Korrektheit etwas pingelig

Für die Diskussion um den Namen ist es doch irrelevant, ob das nun ein Konstruktor oder eine Datei ist...

Leonidas hat geschrieben: Eigentlich hatte ich auch so etwas im Kopf (wenn nich deprecated dann encouraged to use file()), aber nachdem ich noch mal in der Dokumentation zu file() und zu open() zur sicherheit nachgeschaut habe, steht dort etwas anderes.

Ich habe die Weisheit aus einem Buch

. In Python GE-PACKT (2. Auflage)wird auf der Seite 185 folgendes zu open() geschrieben:

Die Funktion open() leistet das Gleiche wie file(), sollte aber heute nicht mehr verwendet werden, sie gilt als >>deprecated<<.

Auf verschiedenen Seiten im Internet wird das auch so dargestellt (Beispiel).

BlackJack hat geschrieben:Das mit dem Alias stimmt ab Python 2.5 nicht mehr. In 2.4:

Jogurt meinte auch nur, dass es ein Alias für den Konstruktor ist. Und das stimmt nach wie vor.

Aber entweder macht die Funktion jetzt schon etwas anderes, oder es ist geplant, dass die in Zukunft etwas anderes macht. Also ist es nicht ganz so egal welches von beiden man zum öffnen von Dateien benutzt. Oder es wurde so gelöst, damit niemand von `open` erbt. Das wäre aber IMHO eine schwache Begründung.

Wieso?
"open" dürfte bei Python <= 2.4 in etwa so:

Code: Alles auswählen

open = file

, in Python 2.5 so definiert sein:

Code: Alles auswählen

def open(*args, **kwargs):
  return file(*args, **kwargs)

Sie ist jetzt also kein Alias für file mehr, sondern ein Alias für den Aufruf des Konstruktors. Ein Aufruf von open() ist also nach wie vor ein Aufruf des File-Konstruktors.

Stephan hat geschrieben:
Leonidas hat geschrieben: Eigentlich hatte ich auch so etwas im Kopf (wenn nich deprecated dann encouraged to use file()), aber nachdem ich noch mal in der Dokumentation zu file() und zu open() zur sicherheit nachgeschaut habe, steht dort etwas anderes.
Ich habe die Weisheit aus einem Buch . In Python GE-PACKT (2. Auflage)wird auf der Seite 185 folgendes zu open() geschrieben:
Die Funktion open() leistet das Gleiche wie file(), sollte aber heute nicht mehr verwendet werden, sie gilt als >>deprecated<<.
Auf verschiedenen Seiten im Internet wird das auch so dargestellt (Beispiel).

Ich frage mich, woher diese Behauptung stammt. Die Python Dokumentation behauptet auf jeden Fall gegenteiliges:

Python 2.4.4 hat geschrieben: The intent is for open() to continue to be preferred for use as a factory function which returns a new file object. The spelling, file is more suited to type testing (for example, writing "isinstance(f, file)").

Python 2.5 hat geschrieben: When opening a file, it's preferable to use open() instead of invoking this constructor directly.

Außerdem gibt es ja auch keine Warnung bei der Verwendung von open().

Gruß
lunar

lunar hat geschrieben:Ich frage mich, woher diese Behauptung stammt. Die Python Dokumentation behauptet auf jeden Fall gegenteiliges:
Python 2.4.4 hat geschrieben: The intent is for open() to continue to be preferred for use as a factory function which returns a new file object. The spelling, file is more suited to type testing (for example, writing "isinstance(f, file)").

Python 2.5 hat geschrieben: When opening a file, it's preferable to use open() instead of invoking this constructor directly.

Ich tippe mal daher:

Python 2.2 und Python 2.3 hat geschrieben:The file() constructor is new in Python 2.2. The previous spelling, open(), is retained for compatibility, and is an alias for file().

Retained for compatibility klingt für mich wie "wir würden open() loswerden, wenn es nicht so viel legacy-Code geben würde". Diese Formulierung lädt meiner Meinung nach dazu ein, file() statt open() zu verwenden.

Verhindern von open zu erben ist könnte durchaus ein Grund sein, aber andererseits, wer schreibt schon class MyFIle(open)?

Das deutsche Python-Forum

file() vs. open()

file() vs. open()