Das deutsche Python-Forum

Hallo

ich bin ein relativ unerfahrener Python Progamierer und habe folgende Frage ich schreibe mit Hilfe von YAML ein paar variablen in eine Datei.
Jetzt stehen die Daten auch in dieser Datei.

({xse: 2206, yse: 371, winkel: 6.0498779844552217, xof: 56, xuf: 2262, yof: 1093, yuf: 371})

Jetzt möchte ich diese Daten wieder in einem anderen Python Programm verwenden, aber ich weiß leider nicht wie ich sie wieder auslesen kann.
Danke schon mal für die Hilfe

yaml.load? Das wird doch sicher dokumentiert sein, im Zweifel würde ich vermuten dass es sich ähnlich dem (c)pickle Modul aus der stdlib verhält oder simplejson.

Na komm. Wenn ich mit Google nach "python yaml" suche, finde ich als ersten Treffer PyYAML und dort steht doch weiter unten auf der Seite ein Beispiel, in dem man sehen kann, dass `yaml.load` eine YAML-Datei lesen kann.

Wenn du es geschafft hast, dir YAML zu installieren (was ja nicht Teil von Python ist) dann musst du doch schon mal genau auf dieser Seite gewesen sein oder aber zumindest von PyYAML gehört haben.

Stefan

Übrigens, ich würde ja benutzen, da sich dies in Python wesentlich besser liest.

Und bist du auf YAML festgelegt? Da es eine externe Bibliothek ist, finde ich es total lästig, diese erst extra installieren zu müssen. Bei Python 2.6 gibt es JSON-Unterstützung. Das Format könnte für deinen Zweck genauso gut geeignet sein. Schließlich kannst du auch einfach `repr(yaml_out)` in eine Textdatei schreiben und dann wieder mit `eval` einlesen, wenn du garantieren kannst, dass niemand dir in deine Datei "bösen" Code schreibt. Bei Python 2.6 gibt es außerdem eine Variante für eval, mit der man garantieren kann, dass nur Literale gelesen werden.

ja diese seite kenne ich mein hauptproblem ist aber das ich ja eine Datei auf meiner Festplatte habe die die daten ja enthält.
ich aber nicht weis wie ich die jeweiligen Daten auslesen kann da ich die werte ja auch als integer benötige
Wenn ich dies mache kommt immer der fehler.:

<closed file '<uninitialized file>', mode '<uninitialized file>' at 0x01395F50>

Das scheint ein generelles Problem beim Verständnis von Dateien zu sein. Du öffnest die Datei zum Schreiben (``w``), da kannst du sie nicht sofort zum Lesen verwenden. Du musst sie schließen und zum Lesen (``r``) öffnen.

Xisto hat geschrieben:

Code: Alles auswählen

yaml.load(yaml.dump(yamlFile))

Dies versucht ja auch den File-Handle zu "dumpen", nicht irgendwelche Objekte. Das macht wenig Sinn. Im deinem ersten Beispiel stand da noch richtiger "yamlOut".

Stefan

``yaml.safe_load()`` bietet sich an.


sma: In Punkto "mitgeliefert" mag JSON seit 2.6 ein Vorteil sein und ich haber daher (und weil man bei AJA[X]-Gefrickel ohnehin meist irgendwo JSON benutzt) öfter schon die Umstellung erwogen und/oder durchgeführt. Noch ist 2.6 in meinen Augen nicht weit genug verbreitet (nicht zuletzt wg. Debian [Lenny-Release] und Ubuntu [noch kein "Jaunty"-Repo]). Dazu kommt, dass JSON im Gegensatz zu YAML Strings unbedingt mit Anführungszeichen begrenzt. Dadurch ist YAML von Anwendern deutlich leichter zu schreiben (und zu lesen, aber das halte ich für weniger wichtig), was vermutlich auch die Popularität von YAML in der Ruby-Welt für die Konfiguration (z. B. bei Rails) mit erklären dürfte.

Das Thema Geschwindigkeit mag in den meisten Fällen nicht so bedeutend sein, rechtfertigt aber bei Bedarf gewöhnlich eine zusätzliche Abhängigkeit. Das komplexere YAML (Superset von JSON) dürfte, gerade bei der Auswertung von eigenen Typen, deutlich hinter dem (aus gutem Grund) sehr begrenzten JSON zurück stehen. Dazu kommt, dass die simplejson-Version in der Standardlib langsamer als die separate Version sein soll und IIRC auch nicht die C-Erweiterungen mitbringt/nutzt [citation needed].

``simplejson`` ist in der Tat schneller als das in 2.6 integrierte ``json``, aber das wird in einem der folgenden Releases (2.6.1 oder 2.7, vermutlich auch in 3.0, weiß nicht genau wie das dann gehandhabt wird) aktualisiert. Nicht dass es mit der Geschwindigkeit von ``json`` Probleme geben sollte.

Die Popularität von YAML in der Ruby-Welt erkläre ich mir daher weil es von dort ursprünglich stammt und seit 1.8.x (wobei mir das exakte x nicht bekannt ist) in der Stdlib von Matz-Ruby mitgeliefert wird (Syck von _why).

Unterschiedliche Performance wird IMHO in den allermeisten Anwendungen, wo ein paar Konfigurationsdaten gelesen werden, keine Rolle spielen.

Ich mag einfach keine externen Bibliotheken, die man auch noch je nach Plattform speziell kompilieren muss, weil sie C-Anteile haben. Das behindert die plattformübergreifende Entwicklung und gibt uns (das ist auf die Python-Entwickler in der Firma bezogen) einen schwereren Stand gegenüber Java. In der Firma z.B. haben wir Vista, OS X und Ubunutu als Betriebssysteme und wollen unsere Programme aus einem gemeinsamen Repository möglichst ohne spezielle Installationen betreiben.

Ansonsten: Ja, das man bei YAML keine Anführungszeichen um Strings herum setzen muss, kann nett sein, widerspricht aber der explizit ist besser Philosophie von Python, oder? Man kann "Scalaren" nicht ansehen, ob es Zahlen oder Zeichenketten sind.

Ich halte YAML auch im Gegensatz zu XML oder JSON oder S-Ausdrücken für viel zu kompliziert. In dem ursprünglich ehrenhaften Versuch, eine lesbare Alternative zu XML zu schaffen, ist man IMHO an Featurities gestorben.

Stefan

sma hat geschrieben:Ansonsten: Ja, das man bei YAML keine Anführungszeichen um Strings herum setzen muss, kann nett sein, widerspricht aber der explizit ist besser Philosophie von Python, oder? Man kann "Scalaren" nicht ansehen, ob es Zahlen oder Zeichenketten sind.

Ja, ich glaub das war auch eine Sache, wo die Ursprünglichen Entwickler von PyYAML auseinandergedacht haben, so kann ich mich erinnnern, dass es einen "Strings are king" Fork gab, der ich glaube dort alles als Strings behandelt hat - wollte man etwas anderes, dann musste man explizit konvertieren.

Die Alles-ist-ein-String-Sichtweise in XML stinkt da natürlich auch ab. Wer's sauber will, nimmt JSON. Ansonsten kann YAML Strings auch in Anführungszeichen einschließen, darüber lässt sich ja vielleicht was deichseln.

Y0Gi hat geschrieben:Die Alles-ist-ein-String-Sichtweise in XML stinkt da natürlich auch ab. Wer's sauber will, nimmt JSON.

XML-Schemata existieren, man kann auch in XML Datentypen verwalten.

Schema-Validierung findet bei XML aber nicht bereits automatisch im Parser statt. Genau genommen weiß ich gar nicht auf Anhieb, ob das mit Stdlib-Bordmitteln überhaupt geht. Wer weiß mehr?

Genau genommen weiß ich gar nicht auf Anhieb, ob das mit Stdlib-Bordmitteln überhaupt geht. Wer weiß mehr?

Keine Ahnung, ich nutze die Module der Standardbibliothek nicht, da sie lxml unterlegen sind. Die ElementTree-Implementierung der Standardbibliothek unterstützt ja noch nicht mal XPath.

lunar hat geschrieben:Die ElementTree-Implementierung der Standardbibliothek unterstützt ja noch nicht mal XPath.

Ach XPath, das wäre ja ok; aber warum hat ElementTree kein ``parent()`` auf Nodes, so wie lxml das hat? Zum navigieren finde ich das nämlich recht praktisch.

Nu hackt mal nicht so auf ET rum. Das war für mich damals eine echte Offenbarung (nochmal +1 für Pure-Python; Webspace und so) und es ist offensichtlich, wieviel lxml ET zu verdanken hat. Das nennt sich Evolution, ist 'ne tolle Sache und vielleicht dürfen wir ja bald lxml in der Stdlib begrüßen.

lunar: Entnehme ich deiner Aussage dann richtigerweise, dass Schema-Validierung mit lxml möglich ist?

Siehe Validation.

Was lxml und ETree angeht: Mir ist schon klar, dass lxml von Freds ETree profitiert hat. Allerdings hab ich bei Python schon immer ETree genutzt, mit DOM war ich nach .NET und Java fertig. Und mit der Qualität der Software steigen die Ansprüche

Y0Gi hat geschrieben:Das nennt sich Evolution, ist 'ne tolle Sache und vielleicht dürfen wir ja bald lxml in der Stdlib begrüßen.

Unwarscheinlich, libxml2 und libxslt1 sind recht happige Dependencies. Obwohl ET nett ist muss ich sagen, dass ich einige Sachen wenig pythonisch finde, da hätte man durchaus ein paar Operatoren überschreiben können und ein paar Properties springen lassen können. Natürlich hat ET eben das Problem, dass es da war, bevor einige coole Python-Features dazugekommen ist, die die API angenehmer hätten machen können.