XML war und ist in Python ein Rough Spot (neben WebApplication-Frameworks). Nichts mit “There’s Only One Way To Do It”. Die XML-Komponenten der Standard-Library sind eher ein Witz und man kann deshalb aus vielen alternativen Implementierungen auswählen. Da hat man dann meistens die Wahl zwischen Pythonic aber langsam/featurearm und seltsamer API, dafür aber schnell und mächtig. Dazu kamen seltsame Benchmarks–Fights in der Community.
Auf der einen Seite hat mir libxml2 gefallen, hauptsächlich wegen der Empfehlung von Mark Pilgrim, der muss es ja wissen :) Auf der anderen — pythonic — Seite hat es mir ElementTree sehr angetan. Nachdem ich das benutzt hatte wollte ich nie mehr Java-Code schreiben der mit XML zu tun hat. ElementTree kann aber kein XSLT und nur eingeschränkt XPath und so musste ich halt mehrere Libraries verwenden, was mich doch gestört hat.
Dank Martijn Faassen hat sich das jetzt aber geändert. Denn der hat einen extrem kühlen Wrapper geschrieben, mit dem man libxml2/libxslt über die ElementTree-API ansprechen kann. lxml ist zwar teilweise noch etwas buggy (aufgrund des Memory-Managements von libxml), aber gut benutzbar und ein schöne und praktikable Lösung um in Python mit XML zu arbeiten.
Ich konnte den mit ElementTree geschriebenen Teil eins-zu-eins mit lxml weiter benutzen und hab jetzt eine Abhängigkeit weniger in meinem Projekt.
Ich glaube man muss aufpassen, wenn man aus der Java-Welt kommt und den dort üblichen Pattern-Overkill auf Python überträgt. Zudem viele Standard-Pattern aufgrund der Dynamik der Sprache nicht unbedingt gebraucht werden oder es bessere Lösungen gibt.
Nichstdestotrotz hatte ich mal wieder einen Wow-Effekt, beim Versuch eine Factory für meine Klassen zu bauen. Nachdem ich einige Zeit mit Modulen und Packages in Python gekämpft hatte — das ist halt doch etwas anders als in Java — hatte ich ein Modul Bookmarks, in dem meine Klassen für die Bookmark-Repräsentation der unterschiedlichen Browser gesammelt waren (Safari, Firefox und Camino). Die Factory-Methode ist als Funktion des Moduls implementiert, also keiner Klasse zugeordnet und soll mir eine Safari-Klasse geben, wenn ich sie mit dem String “Safari” aufrufe. Nichts leichter als das;
def factory(className, *args): aClass = getattr(__import__(__name__), className) return apply(aClass, args)
die erste Zeile mit dem getattr-Aufruf sorgt dafür, dass ich über einen String die Objekt-Referenz bekomme. Der komische erste Parameter gibt mir die Referenz auf das Modul, in dem ich mich gerade befinde, sonst müsste ich von außerhalb des Moduls das getattr aufrufen und die Factory dann mit der Referenz auf das Objekt aufrufen.
Die praktische apply-Methode erzeugt mir nun meine Klasse mit allen Parametern, die ich als zusätzliche Parameter übergebe, z.B.:
importer = Bookmarks.factory('Firefox', firefox_file)
Das rockt ;-)
Apropos DesignPattern: Aus der Head-First-Serie von O’Reilly ist ein Titel über DesignPatterns erschienen. Sieht sehr vielversprechend aus, denn das Head First Java und das ganze Konzept der Serie hat mir gut gefallen. Und die Literatur über Pattern ist eher mau. Das GangOfFour ist nicht mein Ding, das freie Thinking in Patterns von Bruce Eckel ist bisher mein Favorit.
Muss mal kurz ein paar Tabs loswerden und die ganzen Links zu IDEs für Python an einem Punkt sammeln:
In Python ist es mithilfe des getopt-Modul eh schon relativ einfach die Argumente und Optionen von Shellscripts zu verarbeiten. Noch einfacher und eleganter wird es, wenn man optionparse benutzt. Die schöne Idee: Wenn ich schon im Docstring (sozusagen das usage für das Script) die Argumente spezifiziert habe, warum dann nochmals für das getopt-Modul alles genau angeben.
Also einfach den Docstring parsen und daraus die Argumente herausziehen:
"""An example script invoking optionparse, my wrapper around optparse.
usage: %prog [options] args -p, --positional: print positional arguments -1, --option1=OPTION1: print option1 -2, --option2=OPTION2: print option2 """
import optionparse opt, args = optionparse.parse(__doc__) if not opt and not args: optionparse.exit() if opt.positional: print args if opt.option1: print opt.option1 if opt.option2: print opt.option2
Da machen Shellscripte noch mehr Spaß, vorallem wird man auch gezwungen nen sinnvollen Docstring zu schreiben ;-)
Um meine selbst zusammengehackten Python-Kenntnisse mal auf ein solidieres Fundament zu stellen habe ich etwas getan, was ich schon lang nicht mehr gemacht habe: Ein Buch gekauft und *tada* es komplett durchgelesen ;-)
Über Python gibt es mittlerweile eine ganze Menge an Büchern und nach einiger Recherche hatte sich die Auswahl auf die beiden von O’Reilly Python in a Nutshell und Learning Python verringert.
Learning Python ist mehr an Anfänger gerichtet wogegen das Nutshell Buch ein eben typisches Nutshell ist, kompakte und detaillierte Beschreibung der Sprache.
Ich hab mich dann für Learning Python entschieden, da es gerade in einer zweiten Edition rauskam und damit aktueller ist und mich das Probekapitel des Nutshell-Buchs doch etwas gelangweilt hat (und Amazon hatte gerade ein Sonderangebot *g*). Und auch wenn das Learning Python-Buch teilweise für Anfänger geschrieben ist (z.B. was ist OOP) war es die richtige Entscheidung denn es ist gut und verständlich geschrieben und hat mir denke ich die Python-Konzepte besser erklärt als die kompakte Beschreibung des Nutshell-Buchs.
Also wer auf der Suche nach ner schönen und umfassenden Einführung in Python ist sollte sich Learning Python mal angucken. Zudem ist qualitativ gut gemacht: ziemlich dünn für 600 Seiten und schöne Typo.
When Pythons Attack – Common Mistakes of Python Programmers. Auf die meisten Sachen kommt man nach ner Weile auch selbst, aber schön zusammengstellt. Nützlicher ist sicherlich die zweite Seite.
Don’t Code C in Python
Bin stark am überlegen mir das Learning Python, 2nd Edition zu kaufen (was zeigt das oreillynet funktioniert) um die ganze Python-Sache mal auf ne solide Basis zu stellen. Obwohl es für Python jede Menge guter Online-Bücher gibt. Mal noch ein paar Reviews lesen.