@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 ^^.
PyBlogger, guter Code, schlechte Code... das ist hier die...
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Wo ist der Vorteil?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.
``open()`` ist zum Öffnen von Dateien gedacht, ``file`` zum Erben um ``file``-like-Objekte zu erzeugen.Crazed hat geschrieben:"Benutze nicht `file`, sondern einfach `open`." -> Wo ist der Vorteil? Meines erachtens machen die beiden Funktionen fast das gleiche.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
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.
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.
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.veers hat geschrieben:Tut es, jedoch auch transparent.lunar hat geschrieben:Afaik nicht.Crazed hat geschrieben:EDIT: Was mir wirklich noch interessiert, muss Mako auch irgendwas kompilieren?
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."Benutze nicht `file`, sondern einfach `open`." -> Wo ist der Vorteil? Meines erachtens machen die beiden Funktionen fast das gleiche.
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."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.
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
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
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
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.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
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".
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
- User
- Beiträge: 1219
- Registriert: Mittwoch 28. Februar 2007, 20:01
- Wohnort: Zürich (CH)
- Kontaktdaten:
Nein, ich hab es auf das Kompilieren der Templates bezogen.lunar hat geschrieben: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.veers hat geschrieben:Tut es, jedoch auch transparent.lunar hat geschrieben:Afaik nicht.Crazed hat geschrieben:EDIT: Was mir wirklich noch interessiert, muss Mako auch irgendwas kompilieren?
[url=http://29a.ch/]My Website - 29a.ch[/url]
"If privacy is outlawed, only outlaws will have privacy." - Phil Zimmermann
"If privacy is outlawed, only outlaws will have privacy." - Phil Zimmermann
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 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.
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.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.
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
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Nicht ganz zum Thema passend, aber..
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.sma hat geschrieben:den schlechten auf Reference-Counting basierenden GC von Python
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice