[Python-de] Bei der Instantiierung einer Funktion Code ausführen

[Albert Hermeling]

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