PyBlogger, guter Code, schlechte Code... das ist hier die...

[Crazed]

Gut, danke für die vielen Tipps.

Ich habe mich jetzt letzendlich für Jinja2 entschieden. Da mir Jinja schon so viel Arbeit abnimmt brauchte ich noch nicht mal mehr OOP.

http://paste.pocoo.org/show/bH87mMukRlzxAssjT74h/

Ich weiß nicht wie gut oder effizient der Code ist. Falls es gravierende Sachen gibt die ich total dumm gemacht habe, macht mich bitte darauf aufmerksam.

MfG,
CracKPod

[Leonidas]

Du hast geöffnete Dateien nicht wieder geschlossen. Sowas sollte mam nicht tun. Evtl. ist es sogar sinnvoll hier Context-Manager und das ``with``-Statement zu nutzen.

[str1442]

Du schließt die Dateien, die du öffnest, nicht.
Statt "c in '_-'" würde ich mit einem lokal definiertem Tupel arbeiten, eine solche Prüfung kommt der Aufgabe von Tupeln näher.
Die Strings würd ich noch in Variablen packen und vielleicht os.path.splitext in ein eigenes lambda packen und die einzelnen Komponenten zurückgeben lassen.
Und statt filter itertools.ifilter benutzen, ist schneller für die paar Wegwerflisten.

Und die Art wie du Blog Einträge speicherst würde ich überdenken ^_^. Das sind im Grunde doch nur Dictionaries? Dann benutz doch "shelve".

[veers]

EDIT: Was mir wirklich noch interessiert, muss Mako auch irgendwas kompilieren?

Afaik nicht.

Tut es, jedoch auch transparent.

Mmmh, reden wir hier beide über das gleiche Kompilieren? Jinja2 compiliert eine _speedups.so, beim – zugegebenermaßen groben – Durchsehen des Mako-Eggs hab ich aber keine Binaries entdecken können.

Nein, ich hab es auf das Kompilieren der Templates bezogen.

[lunar]

Statt der eigenen Klasse Template kannst du string.Template benutzen. Mako und co. brauchst du nur, wenn du auch deren Features haben willst, da die Abhängigkeit von anderen Modulen (gerade wenn man im Fall von Jinja noch einen C-Compiler installiert haben muss, wie ich das aus der Diskussion verstanden hatte) ein Preis ist, der auch Wert sein muss, bezahlt zu werden.

Jinja2 benötigt keinen C-Compiler, es nutzt das C-Modul nur zur Beschleunigung einiger Operationen. Der Geschwindigkeitsunterschied ist aber bei der einmaligen Erzeugung statischer HTML-Dateien nicht wirklich relevant.

[sma]

Du hast geöffnete Dateien nicht wieder geschlossen. Sowas sollte mam nicht tun. Evtl. ist es sogar sinnvoll hier Context-Manager und das ``with``-Statement zu nutzen.

Bei einem Skript, das einige Sekunden läuft und eine feste Anzahl von Dateien öffnet, finde ich das total egal zumal man dort endlich mal den schlechten auf Reference-Counting basierenden GC von Python zum Vorteil nutzen kann: Er wird die Dateien sehr viel schneller schließen als ein "echter" GC und daher ist es IMHO extrem unkritisch, das die Datei-Handle-Belegung angeht.

Stefan

[lunar]

Die Arbeitsweise des GC ist aber eine Implementierungsdetail. Wenn man sicher ist, dass nur CPython zum Einsatz kommt, ok, aber Jython und IronPython sind ja auch noch da

[Leonidas]

Nicht ganz zum Thema passend, aber..

den schlechten auf Reference-Counting basierenden GC von Python

Du beschwerst dich oft über den GC und auch wenn ich dir zustimme dass Refcounting nicht ganz State of the Art ist würde es mich interessieren: hast du jemals einen Fall gehabt, wo dir der GC von Python Probleme gemacht hat, die du, angenommen du hättest ein CPython mit sagen wir mal einem GC wie den der JVM (soweit ich das sehe ein Generational GC) nicht gehabt hättest? Ich habe die Vermutung dass solche Probleme eher selten sind, aber würde gerne da etwas Ausschluss erhalten. Daher die ernst gemeinte Frage.