Hi Albert, On 2012-12-09 10:03, Albert Hermeling wrote:
Am 09.12.2012 02:55, schrieb Stefan Schwarzer:
Was du beschreibst, macht zudem den Eindruck, als würdest du einen Teil der Funktionalität, die Python schon bietet, noch mal implementieren. So nett DSLs (domain-specific languages) auch scheinen mögen: Nach meiner Erfahrung handelt man sich mit deren Entwicklung und Einsatz oft einen relativ großen Aufwand (in Entwicklung und Fehlersuche) mit relativ wenig Zusatznutzen gegenüber "normalem" Python-Code ein.
Ich glaub jetzt muss ich mal ein kleines Beispiel bringen um das ganze etwas näher zu erläutern:
---Dateianfang---
DOCTYPE = "VERSION : 1.3.0, CHARSET : UTF8, ESC : !/" # Sprachversion und Kodierung;
[f # Normale Sektion f] in_f_1 = <"1" "2" "3"> # Das ist eine Python Liste; in_f_2 = ("10" "20" "30") # Das ist ein Python Tuple; in_f_3 = {"100" "200"} # Das ist ein Python Set [...] ---Dateiende---
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]
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 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)? Falls letzteres, würde ich dringend davon abraten. Du baust damit eine Sprache, die sich so ähnlich wie Python verhält, aber nicht Python ist. _Gerade_ wenn du übliche Python-Syntax verwendest, werden sich Anwender deiner DSL vermutlich früher oder später wundern, warum sie in diesem Kontext nicht beliebige Python-Konstrukte verwenden können. 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.)
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. ;-)
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. 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. Meiner Meinung nach habe ich das gemacht. Aber na ja Geschmäcker sind verschieden; trotzdem hoffe ich, das ihr mein POC nicht in völlig in der Luft zerreißen werdet.:-)
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. Meine Vermutung ist, dass das _langfristig_ weitaus besser zu warten sein wird als ein DSL-Ansatz, auch wenn dir dieser im Moment reizvoller erscheint. [1] http://docs.python.org/2/library/json.html [2] http://trac.edgewall.org/ http://trac.edgewall.org/wiki/TracDev/PluginDevelopment [3] http://mercurial.selenic.com/ http://mercurial.selenic.com/wiki/WritingExtensions Viele Grüße Stefan