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

[Stefan Schwarzer]

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