Hi Albert, On 2012-12-09 13:37, Albert Hermeling wrote:
Am 09.12.2012 12:27, schrieb Stefan Schwarzer:
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.
Klar, sonst _wäre_ es ja schon JSON. ;-) Ich meinte, ich kann mir vorstellen, dass es sich relativ einfach auf JSON übertragen ließe.
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. [...]
Ich will nicht ausschließen, dass für `getattr` die normale Python-Builtin-Funktion verwendet wird. Das Problem, was ich bei diesem Design sehe, ist, dass es, selbst wenn es (nach einem relativ einfachen Parse-Schritt) Python ist, nicht wie Python aussieht. In Python würdest du normalerweise _nicht_ auf _Attribute_ "f.g" zugreifen. Das ist definitiv etwas anderes als `obj.f.g`, was `getattr(getattr(obj, "f"), "g")` entspräche. Also ziemlich exotisch. Klar kannst du `__getattr__`- und/oder `__getattribute__`-Methoden so definieren, dass beides äquivalent ist, aber das finde ich ziemlich gruselig.
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. :-)
Dass es Python-Code ist, ist meines Erachtens nur eine notwendige, aber keine hinreichende Bedingung, um "pythonic" zu sein. :)
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!
Jein. Wie gesagt, sogar wenn man das anfängliche Parsen der Grobstruktur mal außer Acht lässt, sieht es anders als Python aus und hat andere/zusätzliche Regeln gegenüber üblichem Python-Code. Vielleicht mal ein Vergleich: Wenn du deutsche Redewendungen mit den gleichen Wörtern ins Englische überträgst, wird das einen Englisch-Muttersprachler verwirren, selbst wenn Rechtschreibung und Grammatik üblichen Englisch-Regeln folgen (bis auf Ausnahmen, wo Deutsch und Englisch sinngemäß die gleichen Wörter verwenden).
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.
Das habe ich nicht gemeint. Ich fände ein Python-Plugin-System zwar besser als eine spezielle Syntax, wie du sie in deinen Ursprungsdateien verwendest. Ich stimme aber mit Mike überein, dass vielleicht auch schon ein Plugin-System für deine Anwendung zu viel des guten ist.
Aber warum ist es so schlimm wenn ich meine Klassen vor Veränderung Schützen möchte und stattdessen embedded-code zulassen will?
Weil es von üblichen Python-Gewohnheiten deutlich abweicht und der Anwender dieses Systems deshalb auf Besonderheiten gegenüber üblichem Python-Code achten muss. Ich denke, dass die subjektiven Vorteile diesen Nachteil bei Weitem nicht rechtfertigen. Viele Grüße Stefan