typsensitiver Konfigurationsparser

[BlackJack]

@snafu: In der Tat gefällt mir bei Django die Konfiguration als Python-Modul nicht besonders.

Ich weiss nicht wie Du jetzt auf die 99% vs. 1% kommst. Willst Du damit jetzt tatsächlich sagen das nur 1% der Leute die Konfigurationsdateien schreiben mit reinen Daten auskommen und 99% da unbedingt eine komplette Programmiersprache für benötigen weil sie sonst nicht das ausdrücken können was sie benötigen? Halte ich für eine sehr gewagte Aussage. In besagtem PHP-Programm war in der Konfiguration die ich gebraucht hätte nichts was nicht auch in JSON oder YAML hätte ausgedrückt werden können.

`pickle` sollte man dann aber auch auf Grunddatentypen beschränken. Denn die sind nicht wirklich robust gegen Änderungen bei Klassen und der Modul/Packagehierarchie. Und dann kann man auch JSON oder YAML nehmen.

[snafu]

Willst Du damit jetzt tatsächlich sagen das nur 1% der Leute die Konfigurationsdateien schreiben mit reinen Daten auskommen und 99% da unbedingt eine komplette Programmiersprache für benötigen weil sie sonst nicht das ausdrücken können was sie benötigen?

Nein, ich wollte sagen, dass wohl die wenigsten Leute die Konfiguationsdatei in einer anderen Programmiersprache benutzen möchten.

Der vom Threadersteller genannte Fall, dass man eine Konfigurationsdatei automatisiert verändern möchte (z.B. aus administrativen Gründen) und möglicherweise gleichzeitig die Datei noch in einem menschenlesbaren Format vorliegen haben möchte, ist mir allerdings nicht in den Sinn gekommen. Der ist sicherlich auch weniger exotisch.

[Michael Schneider]

`pickle` sollte man dann aber auch auf Grunddatentypen beschränken. Denn die sind nicht wirklich robust gegen Änderungen bei Klassen und der Modul/Packagehierarchie. Und dann kann man auch JSON oder YAML nehmen.

Stimmt, ich hatte auch schon das Problem, dass ich nach der Erweiterung einer Klasse um eine Methode ein gepickeltes Objekt einlas, das die neue Methode gar nicht enthielt.

[Michael Schneider]

Der vom Threadersteller genannte Fall, dass man eine Konfigurationsdatei automatisiert verändern möchte (z.B. aus administrativen Gründen) und möglicherweise gleichzeitig die Datei noch in einem menschenlesbaren Format vorliegen haben möchte, ist mir allerdings nicht in den Sinn gekommen. Der ist sicherlich auch weniger exotisch.

Ja, gut zusammengefasst. In der Regel soll man die direkt editieren. Aber manche Attribute sollten (geht auch ohne, aber wenn es ginge wäre es vorteilhaft) bei Bedarf auch geändert und wieder gespeichert werden können.

[BlackJack]

@snafu: Das man Daten programmiersprachunabhängig speichern möchte hältst Du für exotisch?

[snafu]

Aber manche Attribute sollten (geht auch ohne, aber wenn es ginge wäre es vorteilhaft) bei Bedarf auch geändert und wieder gespeichert werden können.

So wie ich das sehe, musst du dich hier entscheiden:

Möchtest du, dass Python dir die allermeiste Arbeit beim Parsen abnimmt? Dann realisiere die Konfiguration in Python-Dateien, die du halt als Modul importierst. Dann geht aber kein dynamisches Zuweisen von Werten. Oder zumindest beim Abspeichern wäre es ein Problem.

Willst du hingegen nicht auf das dynamische Zuweisen verzichten, dann nimm YAML oder JSON, aber bedenke, dass dann keine komplexen Dinge als Werte mehr möglich sind. Zumindest nichts, was du direkt in die Konfiguration schreiben könntest. Und du müsstest zusätzlichen Code schreiben, der die Werte in passende Python-Typen umwandelt, da du es in dem Fall halt grundsätzlich nur mit Strings zu tun haben wirst.

[snafu]

@snafu: Das man Daten programmiersprachunabhängig speichern möchte hältst Du für exotisch?

Verdreh mir bitte nicht die Worte im Mund. Es geht hier um eine auf ein bestimmtes Programm bezogene Konfiguration, die wiederverwendet werden soll. Das hat nichts mit Daten im allgemeinen zu tun.

[BlackJack]

@snafu: Das hat es eben doch. Konfigurationsdaten sind auch Daten ganz allgemein und warum sollte man die nicht wie allgemeine Daten behandeln? Nur weil Dir nichts einfällt was jemand anders mit einer anderen Programmiersprache damit anstellen können wollte heisst das ja nicht das es solche Fälle nicht gibt. Das kann das klassische „nach 20 Jahren schreibt man das eigene Programm in einer anderen Programmiersprache neu” sein, oder Werkzeuge die Pfade und ähnliches auslesen um von den Daten-/Arbeitsdateien des Programms Sicherungen zu machen, oder Werkzeuge die das Programm ausrollen sollen und an den Konfigurationsdateien rechnerspezifische Änderungen vornehmen, und so weiter. Ich habe mehr oder weniger regelmässig mit Konfigurationsdateien von anderen Programmen zu tun und freue mich immer wenn ich da mit Python ran kann, egal in welcher Sprache die Programme zu den Konfigurationsdateien geschrieben sind. Und es ist unschön wenn die Konfiguration in einer PHP-Datei steckt. In diesem Fall habe ich Teile der Daten duplizieren müssen und bin jetzt darauf angewiesen dass derjenige der die PHP-Datei wartet mir bei Änderungen bescheid gibt, damit ich meine Konfiguration nachziehen kann. Wenn die Konfiguration in einer Python-Datei stecken würde hätte ich zwar Glück weil ich zufällig (gerade) gerne Python für alles mögliche Nutze, aber schön fänd ich das trotzdem nicht.

[Michael Schneider]

Hi Snafu,

Willst du hingegen nicht auf das dynamische Zuweisen verzichten, dann nimm YAML oder JSON, aber bedenke, dass dann keine komplexen Dinge als Werte mehr möglich sind. Zumindest nichts, was du direkt in die Konfiguration schreiben könntest. Und du müsstest zusätzlichen Code schreiben, der die Werte in passende Python-Typen umwandelt, da du es in dem Fall halt grundsätzlich nur mit Strings zu tun haben wirst.

danke erstmal für die Antworten. Aber wenn ich mich nicht täusche, dann wandelt zumindest der JSON Parser die Dateidaten beim Import in entsprechende Typen um. Also Array->Liste, Objekt->Dict, Int->Int. Es war der ConfigParser, bei dem man es grundsätzlich mit Strings zutun hat, die man on-the-fly mit den entsprechenden Methoden typisieren kann. Und den Parserinhalt kann man auch recht komfortabel mit einem .write wieder in die Konfigurationsdatei zurückschreiben. Ich habe mir jetzt, für die einfachen Fälle, .py und ConfigParser vorgemerkt.

Grüße,
Michael

[Michael Schneider]

In diesem Fall habe ich Teile der Daten duplizieren müssen und bin jetzt darauf angewiesen dass derjenige der die PHP-Datei wartet mir bei Änderungen bescheid gibt, damit ich meine Konfiguration nachziehen kann.

Wie ich Dich kenne, hast Du doch schon einen digest der Original-Konfigdatei in Deiner Konfigdatei abgelegt und prüfst beim Skriptstart, ob sich die Original-Konfigdatei geändert hat. Oder?

[DasIch]

Man sollte vielleicht bedenken dass unter "andere Programmiersprache" auch schon Python 3 fällt.

[snafu]

Aber wenn ich mich nicht täusche, dann wandelt zumindest der JSON Parser die Dateidaten beim Import in entsprechende Typen um. Also Array->Liste, Objekt->Dict, Int->Int.

Du hast vollkommen recht. Ich schieb's mal auf die fortgeschrittene Uhrzeit gestern...

[Sirius3]

Ich habe mir jetzt, für die einfachen Fälle, .py und ConfigParser vorgemerkt.

Häh? Versteh ich jetzt nicht, das sind doch die beiden Formate, die bei der ganzen Diskussion hier als die beiden schlechtesten Kandidaten herausgekommen sind. JSON und YAML sind für die allermeisten Fälle, von einfach bis komplex, die besten Wahlen.

[snafu]

Das kann das klassische „nach 20 Jahren schreibt man das eigene Programm in einer anderen Programmiersprache neu” sein, oder Werkzeuge die Pfade und ähnliches auslesen um von den Daten-/Arbeitsdateien des Programms Sicherungen zu machen, oder Werkzeuge die das Programm ausrollen sollen und an den Konfigurationsdateien rechnerspezifische Änderungen vornehmen, und so weiter.

Ich verstehe ja, was du sagen willst. Trotzdem sind Python-Files manchmal bequemer. Ich zwinge ja niemanden, das so zu machen. Aber ich lasse mich auch nicht zwingen, alles in JSON-Notation ausdrücken zu müssen in Fällen, wo der Weg über Python-Files leicher wäre.

Und falls die Konfigurationsdatei meines Programms für jemanden mal sooo wichtig wird, dass er sie in einer anderen Sprache verarbeiten möchte und dazu nicht den Weg über die sonst üblichen Shell-Tools wie `awk` und Konsorten gehen will, dann kann ich ja immer noch einen JSON-Konverter schreiben (oder einen Konverter für eine in 20 Jahren existierende Programmiersprache).

[snafu]

Man sollte vielleicht bedenken dass unter "andere Programmiersprache" auch schon Python 3 fällt.

Ich für meinen Teil schreibe schon seit Jahren meine Python-Programme so, dass sie in beiden Major-Versionen laufen. Das gilt natürlich auch für die Konfigurationsdateien. Falls schon die Konf.datei nicht unter der anderen Major-Version läuft, dann ist die Wahrscheinlichkeit hoch, dass auch das zugehörige Programm dort nicht laufen wird.

[Sirius3]

@snafu: aber Konfigdateien wo in der ersten Zeile ein kryptisches "from __future__ import unicode_literals, division" verwirren doch auch 99% der Nutzer.

[BlackJack]

@Michael Schneider: Das mit dem prüfen auf Änderung habe ich noch nicht eingebaut, ist aber notiert, danke.

@snafu: Das mit dem einfacher ist so eine Sache. Viele Sachen lassen sich sehr einfach mit ``global`` oder `eval()` machen statt umständlich über Argumente oder passende Datenstrukturen. Einfacher ist nicht immer gleich besser.

Deine Annahme das wenn die Konfigurationsdatei nicht mit Python 3 läuft die Wahrscheinlichkeit gering ist das das Programm mit Python 3 läuft lässt mich wieder vermuten dass Deine Konfigurationsdateien keine sind, sondern zumindest teilweise Teil des Programms. Klar startet beides mal als Python 2 aber dann wird das Programm irgendwann mal auf Python 3 portiert und dann hat man das Problem das es die Konfigurationsdatei von der vorhergehenden Version lesen können muss. Falls das Programm also portiert wird ist die Wahrscheinlichkeit 100% das man in genau diese Situation läuft.

[snafu]

@BlackJack: Möglicherweise haben wir tatsächlich eine unterschiedliche Definition von Konfigurationsdatei und reden daher aneinander vorbei.