Moin, ich hab die Erfahrung gemacht, dass es besser ist, etwas länger über die verwendeten Datenstrukturen nachzudenken anstatt sich den Kopf über den Code zu zerbrechen. Allerdings habe ich jetzt ein Problem, zu dem ich keine Lösung finde, die mir 100% gefällt. Zum Problem: ich muss in mehreren Kontexten Konfigurationen anderer Programme parsen und/oder wegschreiben. Die sieht typischerweise so aus: define someobject { attribute_x yes attribute_y 2220 attribute_z something with spaces } Es kommen auch verschachtelte Objekte vor, also so etwas: define nesteobject { name foo style bar subobject barney { name rubble friend fred } } Wie stellt man so etwas geschickter Weise als Python-Objekt(e) dar. Wenn barney kein eigenes Objekt ist, ist das kein Problem, die Redundanz ist an dieser Stelle gering. Allerdings wäre mir einfacher Zugriff auf die Attribute wichtig. "Einfach" vor allem im Sinne von wenig Tipperei und leichter Lesbarkeit. Dabei kann es vorkommen, dass nicht alle Attribute belegt sind - dann "None" zu liefern statt eine Exception zu werfen ist vorzuziehen; ideal wäre aber, das konfigurierbar zu machen. Ich weiss, dass man die Attribute einfach in den Namespace eine Klasse kippen könnte, aber da besteht natürlich die Gefahr, dass das Attribut "foo" die Methode foo() übermalt - sehr unschön. Wegschreiben der Objekte ist ja relativ einfach zu lösen, wobei man dort natürlich aufpassen muss, dass nur die Attribute ausgegeben werden, die relevant sind (die Methoden zB nicht). Vorschläge? Gruss, Tobias -- fs_dprintk (FS_DEBUG_INIT, "Ha! Initialized OK!\n"); linux-2.6.6/drivers/atm/firestream.c
Hallo Tobias, On 2008-05-31 16:07, Tobias Klausmann wrote:
das sehe ich genauso. Noch besser ist vielleicht, zuerst an die Schnittstelle zu denken und die Datenstruktur "dahinter" zu verbergen. Dann kann man die interne Datenstruktur und die entsprechenden Zugriffsalgorithmen auch hinterher noch ändern, ohne den Code zu ändern, der die Schnittstelle verwendet.
Wenn es nicht auf die Reihenfolge der Attribute ankommt, nimm vielleicht ein verschachteltes Dictionary und verberge das in einer Klasse. Also in etwa # Klassenname möglichst aussagekräftiger wählen class Container(object): def __init__(self, ...): self._data = {} ... _data nimmt die eigentlichen Daten auf, so gibt es auch keine Konflikte zwischen Datenattributen und Klassenattributen. Denk im Hinblick auf die Schnittstelle auch daran, dass du mit Propertys [1] arbeiten kannst, also nicht unbedingt explizite Methodenaufrufe verwenden musst, wenn sich diese "unnatürlich anfühlen". Unabhängig vom oben Gesagten solltest du dir aber auch überlegen, inwieweit du "üblichere" Datenformate verwenden kannst, zum Beispiel das vom ConfigParser-Modul [2] verwendete Format oder XML. Bei letzterem gibt es mit elementtree [3] oder lxml [4] schon Bibliotheken, die das Lesen und Schreiben verschachtelter Strukturen schon eingebaut haben. Gegen XML spricht dann höchstens, dass es nur relativ umständlich in einem normalen Editor zu schreiben ist. [1] http://users.rcn.com/python/download/Descriptor.htm [2] http://docs.python.org/lib/module-ConfigParser.html [3] http://docs.python.org/lib/module-xml.etree.ElementTree.html [4] http://codespeak.net/lxml/ Viele Grüße Stefan
Hallo Tobias, On 2008-05-31 16:07, Tobias Klausmann wrote:
das sehe ich genauso. Noch besser ist vielleicht, zuerst an die Schnittstelle zu denken und die Datenstruktur "dahinter" zu verbergen. Dann kann man die interne Datenstruktur und die entsprechenden Zugriffsalgorithmen auch hinterher noch ändern, ohne den Code zu ändern, der die Schnittstelle verwendet.
Wenn es nicht auf die Reihenfolge der Attribute ankommt, nimm vielleicht ein verschachteltes Dictionary und verberge das in einer Klasse. Also in etwa # Klassenname möglichst aussagekräftiger wählen class Container(object): def __init__(self, ...): self._data = {} ... _data nimmt die eigentlichen Daten auf, so gibt es auch keine Konflikte zwischen Datenattributen und Klassenattributen. Denk im Hinblick auf die Schnittstelle auch daran, dass du mit Propertys [1] arbeiten kannst, also nicht unbedingt explizite Methodenaufrufe verwenden musst, wenn sich diese "unnatürlich anfühlen". Unabhängig vom oben Gesagten solltest du dir aber auch überlegen, inwieweit du "üblichere" Datenformate verwenden kannst, zum Beispiel das vom ConfigParser-Modul [2] verwendete Format oder XML. Bei letzterem gibt es mit elementtree [3] oder lxml [4] schon Bibliotheken, die das Lesen und Schreiben verschachtelter Strukturen schon eingebaut haben. Gegen XML spricht dann höchstens, dass es nur relativ umständlich in einem normalen Editor zu schreiben ist. [1] http://users.rcn.com/python/download/Descriptor.htm [2] http://docs.python.org/lib/module-ConfigParser.html [3] http://docs.python.org/lib/module-xml.etree.ElementTree.html [4] http://codespeak.net/lxml/ Viele Grüße Stefan
participants (2)
-
Stefan Schwarzer -
Tobias Klausmann