Skip to content

1 Tag, 3 sehr praktische Py-Bibs

Zur Zeit mache ich ziemlich viel -Verarbeitung. Um das ganze pythonischer zu gestalten, parse ich das in eine Dictionary-Implementierung, die sich die Reihenfolge der Einfügungen merkt (Originalcode via Voidspace: OrderedDict) und auf deren Inhalt nicht nur mit dict["schlüsselwert"] zugegriffen werden kann, sondern auch mit dem praktischeren dict.schlüsselwert (meine Erweiterung).

Auf eine XML-Struktur wie wert2 lässt sich damit mit elem1.elem2 zugreifen, um wert2 zu erhalten. Da Attribute sehr spärlich verwendet werden, habe ich mich dafür entschieden, Attribute „flachzudrücken“ und wie Elemente anzusprechen.

Diese Dict-Implementierung wollte ich erweitern ohne das bisherige Verhalten zu ändern, schließlich verwende ich es an vielen Stellen. Was also tun? Den Ist-Stand mit fixieren!

Richtige UnitTests zu schreiben schien übertrieben – da viel mir doctest ein. Mit diesem -Modul, das in der Standardbibliothek enthalten ist, kann man die Tests direkt im Docstring für Module, Klassen, Methoden und\oder Funktionen hinterlegen. Diese Tests werden dann dort gefunden und ausgeführt. In der Standardeinstellung bekommt man nur bei einem Fehler was davon mit.

Wie werden die Tests gefunden? Die Tests sehen aus wie Interaktionen mit dem Interpreter, in Pythons Fall beispielsweise Idle.

Von hört man immer wieder, bislang nahm ich das aber nicht sonderlich ernst. Bis gestern. Das Teil ist wirklich sehr, sehr praktisch: Die Dokumentation ist der Test, der Test ist die Dokumentation (LiterateProgramming). Sehr cool, wenn man es sich so überlegt.

Das oben angesprochene XML verwende ich u.a. dazu Java-Code zu generieren (CodeGeneration). Bis gestern habe ich den Code ín eine (versionierte) Datei generiert, deren Inhalt ich dann an die gewünschte Stelle im Source kopiert habe. Die Versionierung ist praktisch, weil man so leicht ungewollte Änderungen feststellen kann.

Das Kopieren ist umständlich und also nichts für mich. Da habe ich mich an Cog erinnert. Cog ist eine Bibliothek, mit der man Pythoncode zum generieren von beliebigem anderen Code direkt im Ziel-Quellcode einfügt und dann per CLI die Codegenerierung anstößt. Der Pythoncode bleibt dabei erhalten, der generierte Code wird eingefügt bzw. bereits vorhandener erneut generiert. So kann man den Code immer wieder aktualisieren. Sehr, sehr praktisch. Und sehr cool.

Als letztes möchte ich WMI erwähnen, mit diesem Modul kann man bequem auf die WindowsManagementInstrumentation zugreifen. Ich verwende es seit gestern dafür, auf einem entfernten Rechner einen Service neu zu starten, nachdem ich Änderungen an dessen Konfiguration vorgenommen habe. Da das Verbinden über das -Modul mit dem entfernten Rechner kein Problem war, nehme ich an, dass die aktuelle Windowsanmeldung weitergereicht wird.

Das Modul kann noch viel mehr – man sollte es sich ebenfalls unbedingt ansehen.

Nochmal zur Wiederholung

Happy Hacking!

Post a Comment

Your email is never published nor shared. Required fields are marked *