Am 09.12.2012 12:27, schrieb Stefan Schwarzer: Hallo Stefan,
für mich sieht das JSON so ähnlich, dass ich mich frage, ob du nicht lieber das als "Grundformat" nehmen und dann nur etwas per Software nachbearbeiten willst. JSON wird seit Python 2.6 in der Standardbibliothek unterstützt. [1] Ja ist es und dann wieder nicht. Es gibt schon einige Unterschiede.
Eingelesen wird die Datei so obj = poc_read("test.poc")
Auf die Attribute greift man so zu:
obj.f.in_f_1,
oder so
x = getattr(obj, "f.g.SubS.namen")
Attribute können so neu belegt werden:
obj.f.in_f_1 = "Neuer Wert"
aber auch so:
obj.f.newAttribute("Neuer Wert", "Mit Kommentar")
aber auch so:
setattr(obj, "f.g.SubS.name", ("foo", "bar", "egg"))
Sektionen werden so angelegt:
obj.f.newSection("Foobar", "Sektion Foobar", datatype = "txt")
Gespeichert wird die POC-Hierarchie so:
poc_write(obj) Sind diese Aufrufe alles normale Python-Aufrufe Sind alles ganz normale Python aufrufe dort wird kein parser eingesetzt. getattr, setattr, sind die Originalen Funkionen von Python. Das getattr(obj, "a.b.c") darfst du machen must du aber nicht. Du kast getattr auch mehrmals hintereinander aufrufen. Alle Datentypen wie tuple, set, list usw. sind Original Python Objekte und verhalten sich auch so.
oder musst du das selbst parsen und in echten Python-Code umsetzen ( `getattr(obj, "f.g.SubS.namen")` sieht mir schon stark nach der zweiten Variante aus)? Das einzige was ich parsen muss ist die Datei sonst nichts. Wie willst du mit Erweiterungswünschen "deiner" Anwender umgehen? Sagst du, "geht nicht", oder bildest du mittel- bis langfristig immer mehr von Python nach? (Oder noch unangenehmer: etwas, was nicht Python, sondern nur "so ähnlich" ist.) Ich brauche kein Python nachbilden es ist Python! und nichts anderes.
Was ist daran so Unpythonisch das ein Programmierer das nicht anwenden kann wenn er es denn will! ;-) Unpythonisch wäre es für mich schon mal, wenn es kein Python wäre. ;-) Na das freut mich jetzt aber ungemein, es ist ja Python und nichts anderes. :-)
Wenn die anderen Programmierer sich nicht mit Python auskennen, werden sie vermutlich lästige Fehler in ihrem Code einbauen. Wenn sie sich an dich wenden, darfst du unter Umständen diese Mischung aus DSL und dem anderen Code debuggen. Wenn die Programmierer dagegen erfahrener sind, werden sie voraussichtlich vorziehen, "ganz normales" Python zu schreiben, ohne sich Gedanken über abweichende Ausführungsmodelle machen zu müssen. Also ich sehe POC als normales Python an. Man benützt diese POC-Hierarchie in weiten Teilen, so wie man eine ganz normale Objekt-Hierarchie benützen würde. Das "in weiten Teilen" lässt mich auch wieder aufhorchen. Das "in weiten Teilen" ist ein sau blöder Satz. Entschuldige bitte, ich war da wohl noch nicht ganz ausgeschlafen. Die Weinachsfeier gestern Abend, war doch anstrengender als ich dachte. ; Die Sektions Objekte verhalten sich wie Python Objekte. Das einzigste was Du nicht machen kannst diese Überschreiben, willst du das, musst Du dieser erst löschen. Neu anlegen geht am einfachsten mit newSection. Ein Anwender muss sich bei einem Python-Konstrukt, das er gern verwenden würde, also überlegen, ob das in deiner Sprache überhaupt geht oder anders als in Python geschrieben werden muss. Das ist zusätzliche Denkarbeit, die du bei einer mit "normalem" Python implementierten Schnittstelle nicht hättest.
Fazit: Ich würde eher versuchen, ein Design zu entwickeln, dass sich gut in die normale Entwicklung mit Python einfügt. Ich sage es noch mal es ist keine neue oder andere Programmiersprache es ist Python! Nach dem, was ich bisher gesehen habe, empfehle ich umso mehr, dass du deinen Ansatz noch mal überdenkst.
Hast du mal recherchiert, wie woanders Plugin-Systeme entworfen und implementiert wurden? Ich denke, du solltest, falls du es noch nicht getan hast, erst mal allgemein zum Thema Plugin-Architekturen in Python recherchieren und dann zu speziellen Projekten. An Python-Programmen mit Plugin-Schnittstelle fallen mir schon mal Trac [2] und Mercurial [3] ein. Möglicherweise ist eine Plugin-Schnittstelle viel leichter zu implementieren als du denkst. Vielleicht reicht für dich eine ganz triviale Implementierung. Schön das zumindest die Idee eines Plug-in Systems deine Zustimmung findet.
Aber warum ist es so schlimm wenn ich meine Klassen vor Veränderung Schützen möchte und stattdessen embedded-code zulassen will? Viele Grüße Albert