Re: [Python-de] Frage zum configparser
Am Thu, 19 Jan 2017 22:02:17 +0100 schrieb Arnold Krille:
Hallo Manfred,
tl;dr: Entschuldigung.
On Thu, 19 Jan 2017 17:53:29 +0000 (UTC) Manfred Gil <manfred-gil@t-online.de> wrote:
kann es sein, das Du gestern einen schlechten Tag hattest ;-)
Ja, vielleicht. Entschuldigung falls das Emotionen in mein Email gepackt hat, die bei Dir zu negativen Emotionen geführt haben. Das wollte ich nicht!
vergesse es.. so zart besaitet bin ich ja auch nicht.
Wieso sollte ich mir _nicht_ Gedanken darum machen, ob ich das File wieder schließen sollte. <code> daten = open('READNE.txt','r') text = daten.read() daten.close() print(text)
</code>
ist für mich im ersten Augenblick nichts anderes. Sicher, jetzt kommen alle Python Nerds an und erklären mir den Unterschied, zwischen den beiden code stücken von mir.
Yep, hier kommt einer. Denn:
<fg> wieso wuste ich das ?
Wenn ich Deine ursprüngliche Frage richtig verstehe, dann ist das Beispiel oben nicht passend zu Deiner ursprünglichen Frage. Das Beispiel müsste lauten:
Richtig.
<code> text = read_from_file('READNE.txt') print(text) </code>
Und wenn ich Dich richtig verstehen, denkst Du darüber nach, ob Du das file schliessen musst?
yep, das war mein Urgedanke dabei
Meine Gegenfrage lautet: Welches File?
< Oberlehrer > das "config.ini" File < dumm schau> oder ist das kein File </ dumm schau> </ Oberlehrer geht in die Pause >
Die Implementierung von read_from_file ist nicht bekannt, die Eingabe in die Funktion ist ein Dateiname (und Pfad) als string, die Rückgabe der Funktion ist auch ein string mit dem Inhalt der Datei.
ähm tschuldige... <zitat> Die Implementierung von read_from_file ist nicht bekannt </zitat> die Implementierung von read beim Configparser ist aber bekannt. Richtig? deshalb weiß man(n) das dass File " config.ini " automatisch wieder geschlossen wird. Richtig? Vielleicht etwas dumm Ausgedrückt, doch im Kern richtig?
Wenn Du in Python Dateien selber öffnen willst, dann werden die repräsentiert durch File-Objekte (high level) oder durch file-handles (low level).
Schon mal gelesen, doch Ehrlich, manchmal steige ich gedanklich aus.
So ein File-Objekt erhälst Du, wenn Du 'open("filename", "r")' machst. Ein file-handle ist im Prinzip ein integer, der die geöffnete Datei im Speicher markiert und wird Dir von 'os.open("filename", …)' zurück gegeben.
Das File-Objekt lässt sich schliessen indem man auf dem Objekt '.close()' aufruft, der file-handle wird geschlossen durch 'os.close(handle)'.
Jep, das ist hängen geblieben, deshalb meine Frage nach dem Schließen des File beim Configparser.. [Nerds code] .. bin immer wieder begeistert, auf wie viel Arten man so coden kann.. [ etwas Selbstmitleid von mir Entsorgt]
Tut mir leid wenn ich da gestern (und heute?) etwas Oberlehrerhaft rüber komme. Das will ich gar nicht. Oder meine es zumindest doch nur gut.
ist so angekommen, glaub es mit
Beim Anblick Deiner Frage hatte ich halt zwei Befürchtungen (siehe Svens Vermutung):
Entweder hast Du in Deiner C- und Perl-Erfahrung tatsächlich schon so viele Fälle von so einem Konstrukt gesehen, das Du Dir Deine Originalfrage da tatsächlich sehr häufig so stellen musst. Dann sinken C und Perl in meinem ansehen noch tiefer und ich werde nie wieder eine Zeile davon lesen, geschweige denn schreiben.
Oder Du weißt es einfach noch nicht besser. Was nicht schlimm ist. Wir haben schließlich alle mal angefangen. Dann ist meine Hoffnung, das Du irgendwann (möglichst bald!) soweit bist, das Du Code nicht nur "für Dich" sondern auch "für Alle" schreibst. Und dann möchte ich Dir helfen, das es guter Code ist mit klaren Konzepten und eindeutigen Schnittstellen. Nicht das ich dann irgendwann über Code stolpere, der eine globale Variable nutzt um ein file-Objekt offen zu lassen damit ich es selber schließen muss. Oder so…
Das ist es was ich auch möchte, viele Fragen kann ich meist selbst lösen. Mir ging halt das close nicht mehr aus dem Kopf. Vielleicht sollte man die Python Doku in Bezug auf dem Configparser etwas ändern. Wie in etwa. Beim Einlesen der ini muss kein close gemacht werden. <zu meiner Schande > diese Fach Englisch ist nicht gerade meine Stärke. </ Schande >
Aber na ja, lassen wir das. Hier hatte ich schnelle und unkomplizierte Hilfe bekommen, wie meistens... ne immer :-)
Hm, vielleicht will man nicht nur schnelle Hilfe sondern manchmal auch noch ein wenig über Code und Konzepte philosophieren? Programmieren bzw. Software entwickeln hat meiner Erfahrung immer weniger mit Code und immer mehr mit Nachdenken zu tun je mehr Entwicklungserfahrung man hat.
Ha jetzt hab ich dich.. :-) Ich hab Nachgedacht ob ich das File nicht wieder schließen müste, so als wenn ich eine README Datei öffne um diese zu lesen. :-)
Bis denn,
Arnold
Bis dann Ab Morgen wird weiter Nachgedacht, code geschrieben und getestet. Gruß Manfred -- Man kann gewiß sein, dem andern nicht viel Vergnügen gemacht zu haben, wenn man lauter Sachen sagte, die uns eines machten und so umgekehrt. -- Jean Paul
On 20.01.2017 19:57, Manfred Gil wrote:
[schnippeldischnipp] < Oberlehrer >
das "config.ini" File
< dumm schau>
oder ist das kein File
</ dumm schau> </ Oberlehrer geht in die Pause >
Dateiname und Datei sind etwas unterschiedliches in Python. 'mein-ordner/config.ini' << das ist der Name/Pfad einer Datei open('config.ini') << das, was hier rausfällt, ist quasi die Datei Manche sagen, ne ne ne, das ist der File-Deskriptor (und bezeichnen ihn as fd). Aber praktisch betrachtet, fällt bei open() die Repräsentation der Datei heraus. Und diese muss dann natürlich wieder geschlossen werden. Daher auch üblicherweise die Verwendung mit "with". "with" schließt die Datei automatisch (bzw. für alle Überkorrekten, den File-Deskriptor). Beim ConfigParser erhältst du eine InMemory-Repräsentation der Config-Datei in dem du einen entsprechenden Dateinamen angibst. Was die Bezeichnungen angeht ist das sogar recht konsistent in Python: json.load <<< lädt aus Datei ConfigParser.load <<< lädt aus Datei yaml.load .... open << öffnet Datei, muss geschlossen werden tar.open <<< öffnet Datei, .... Vielleicht als Eselsbrücke. Cheers, Sven
participants (2)
-
Manfred Gil
-
Sven R. Kunze