Das deutsche Python-Forum

@Leonidas, genau das will aber ich aber nicht. Ich möchte das es einfach "out-of-the-box" funktioniert ohne irgendwas zusätzliches installieren zu müsen.

@sma, Ich kenne mich leider kaum mit RegEx aus, wäre eventuell mal ganz gut wenn ich
mich ein bisschen mit der Materie auseinandersetze.

"Erbe nicht von Template. Das ist kein guter Stil." -> Wozu kann man dann erben? bzw. in welcher Situation ist es angebracht? Ich hielt das für sehr elegant.

"Benutze nicht `file`, sondern einfach `open`." -> Wo ist der Vorteil? Meines erachtens machen die beiden Funktionen fast das gleiche.

"Wozu brauchst du eigentlich `imp.load_source`?" -> Ich habe eine komische Art entwickelt blog-posts zu schreiben. Diese sind genau genommen einfach Python dateien in denen ein paar Variablen definiert werden, wie z.b content, author, date und title

"Übergib ein Template als Argument, nicht nur den String." -> Tue ich das nicht bereits?

Ich glaube fast ich packe einfach den nur knapp den Ordner mit der Jinja distribution einfach mit darein und benutze jinja2. Warum denn auch nicht? Dort gibt es viele und sehr komfortable features die ich gebrauchen kann. Außerdem hat man innerhalb des Templates viel mehr freiheit.

Trotzdem vieelen Dank. Ich finde deinen Coding Stil übrigens sehr hübsch und werde mich an einigen von deinen Ideen halten.

Wenn ich mich etwas doof anstelle, tut mir das Leid ^^.

Crazed hat geschrieben:@Leonidas, genau das will aber ich aber nicht. Ich möchte das es einfach "out-of-the-box" funktioniert ohne irgendwas zusätzliches installieren zu müsen.

Wo ist der Vorteil?

Crazed hat geschrieben:"Benutze nicht `file`, sondern einfach `open`." -> Wo ist der Vorteil? Meines erachtens machen die beiden Funktionen fast das gleiche.

``open()`` ist zum Öffnen von Dateien gedacht, ``file`` zum Erben um ``file``-like-Objekte zu erzeugen.

Kid kannst du mal getrost vergessen. Es ist einer der Vorgänger von Genshi und teilweise broken by design. Ich habe über die Unterschiede seinerzeit mal einen kleinen Beitrag auf meiner Website geschrieben, der über das Genshi-Wiki zu finden ist.


ReST benutze ich für die editierbaren Inhalte meiner persönlichen Website ebenfalls mit großer Zufriedenheit und habe damit Markdown abgelöst. Auf einer anderen benutze ich wiederum gewollt Markdown (natürlich mit diversen eigenen, anwendungsspezifischen Erweiterungen) statt ReST, da dort auch weniger technisch versierte und geübte Benutzer Inhalte schreiben und mit der Mächtigkeit von ReST doch ein wenig überfordert wären.

veers hat geschrieben:

lunar hat geschrieben:

Crazed hat geschrieben: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.

"Benutze nicht `file`, sondern einfach `open`." -> Wo ist der Vorteil? Meines erachtens machen die beiden Funktionen fast das gleiche.

File ist eine Klasse die ein File Objekt repräsentiert, open eine Funktion, die File benutzt. Im Grunde ist es egal, welche du nutzt, da die __init__ von file die gleichen Argumente entgegennimmt wie open, aber die Dokumentation empfiehlt die Nutzung von open(). Warum auch immer.

"Erbe nicht von Template. Das ist kein guter Stil." -> Wozu kann man dann erben? bzw. in welcher Situation ist es angebracht? Ich hielt das für sehr elegant.

Template teilt zwar mit allen Unterklassen die Eigenschaften, es ist aber rein logisch ein wenig eigenartig. Das ist in etwa so, als würdest du beim Versuch des Darstellens eines Raumes die Objekte Stuhl, Tisch und Tür von "Holz" erben lassen.

Ich würde in vorliegendem Fall das mittels Komposition lösen, dh alles was mit Templates zu tun hat in einer wohlgeformten Template Klasse unterbringen, und jeder "Page" dann einde Instanz von "Template" geben. Zumindest so auf den ersten Blick.

Vererben sollte man imho wirklich nur Dinge, die zueinander gehören. Sobald du mittels Vererbung die eigentliche Logik der Superklasse in zig andere Klassen schleppst, die so direkt mit einem Template nichts zu tun haben, brichst du die Kapselung.

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

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.

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".

lunar hat geschrieben:

veers hat geschrieben:

lunar hat geschrieben:

Crazed hat geschrieben: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.

sma hat geschrieben: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.

Leonidas hat geschrieben: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

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

Nicht ganz zum Thema passend, aber..

sma hat geschrieben: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.