Das deutsche Python-Forum

Ich vermute mal, ein function call ist noch langsamer als Strings neu zu erzeugen - aber das ist mehr oder weniger geraten.

Man könnte sich ja auch noch die Arbeit antun und eine Templateengine in C programmieren, bzw. eine vorhandene für Python einsatzfähig machen.

lgherby

thelittlebug hat geschrieben:Man könnte sich ja auch noch die Arbeit antun und eine Templateengine in C programmieren, bzw. eine vorhandene für Python einsatzfähig machen.

lgherby

Cheetah hat afaik einen in C optimierten Name Mapper. Und dann gibt es noch ClearSilver wofür es vermutlich auch Python Bindings gibt. Nur frage ich mich gerade wie relevant das überhaupt ist. Ich nehme mal an dass die Template Engine auf eine Normalen Website 1-10% der verbrauchten CPU Zeit ausmacht.

Ich hoffe mal es macht nichts wenn ich etwas vom Thema abweiche. Aber wo wir gerade bei Template Engines sind, was gibt es da was nicht so gross ist (Cheetah ist ja doch fast 1MB), nicht XML Basiert sowie Vererbung unterstützt? Jinja habe ich mir mal angesehen. Sieht nett aus (erinnert an Django) , ist jedoch auch schon Recht gross/mächtig. Mako wirk irgend wie etwas hacky und die Syntax etwas unfreundlich.

Wieso ist es so beliebt Templates in Python Code zu kompilieren, das wirkt auf mich nicht wirklich elegant.

veers hat geschrieben:Wieso ist es so beliebt Templates in Python Code zu kompilieren, das wirkt auf mich nicht wirklich elegant.

Kaum eine Engine macht das auch mit tatsächlich Python code zu erstellen. Mako/Jinja und ich denke einige andere auch interessieren sich nur für den Bytecode und dumpen den (wenn gewünscht) irgendwohin, damit das nächste mal das Template nicht mehr geparst werden muss.

und Jinja hat auch ein optionales C context objekt ^^

blackbird hat geschrieben:Kaum eine Engine macht das auch mit tatsächlich Python code zu erstellen. Mako/Jinja und ich denke einige andere auch interessieren sich nur für den Bytecode und dumpen den (wenn gewünscht) irgendwohin, damit das nächste mal das Template nicht mehr geparst werden muss.

Hm, tönt für mich immer noch etwas nach schwarzer Magie. Aber vielleicht sollte ich es mir auch einfach genauer ansehen.

veers hat geschrieben:

blackbird hat geschrieben:Kaum eine Engine macht das auch mit tatsächlich Python code zu erstellen. Mako/Jinja und ich denke einige andere auch interessieren sich nur für den Bytecode und dumpen den (wenn gewünscht) irgendwohin, damit das nächste mal das Template nicht mehr geparst werden muss.

Hm, tönt für mich immer noch etwas nach schwarzer Magie. Aber vielleicht sollte ich es mir auch einfach genauer ansehen.

Wenn du Wege findest das ohne schwarze Magie zu machen, raus damit. Interpretieren ist eine ziemlich blöde Idee da langsam.

veers hat geschrieben:

blackbird hat geschrieben:Kaum eine Engine macht das auch mit tatsächlich Python code zu erstellen. Mako/Jinja und ich denke einige andere auch interessieren sich nur für den Bytecode und dumpen den (wenn gewünscht) irgendwohin, damit das nächste mal das Template nicht mehr geparst werden muss.

Hm, tönt für mich immer noch etwas nach schwarzer Magie. Aber vielleicht sollte ich es mir auch einfach genauer ansehen.

Magie? Warum? Python unterstützt und fördert doch Introspektion, und der Zugriff auf Codeobjekte aus der Sprache gehört auch dazu.

birkenfeld hat geschrieben:

veers hat geschrieben:

blackbird hat geschrieben:Kaum eine Engine macht das auch mit tatsächlich Python code zu erstellen. Mako/Jinja und ich denke einige andere auch interessieren sich nur für den Bytecode und dumpen den (wenn gewünscht) irgendwohin, damit das nächste mal das Template nicht mehr geparst werden muss.

Hm, tönt für mich immer noch etwas nach schwarzer Magie. Aber vielleicht sollte ich es mir auch einfach genauer ansehen.

Magie? Warum? Python unterstützt und fördert doch Introspektion, und der Zugriff auf Codeobjekte aus der Sprache gehört auch dazu.

Magie weil ich nicht damit vertraut bin und nicht verstehe wie es Funktioniert (Das Prinzip hinter Byte Code und einer VM kenne ich, aber nicht wie es in Python gehandhabt wird). Zudem Magie weil ich vermute dass das ganze ziemlich implementierungsabhängig und undokumentiert ist. Ich mag mich aber böse irren darum auch

veers hat geschrieben:Aber vielleicht sollte ich es mir auch einfach genauer ansehen.

.

Einen eleganteren schnellen Weg kenne ich nicht. Schneller wäre es das ganze in Nativen (Shell)Code zu kompilieren. Ist dann aber nicht nur von der Python Implementierung abhängig sondern sogar von der CPU.

Ich persönlich mag keine Template-Engines mit C-Basis, weil man non-pure-Python-Packages nicht mal eben auf einen Python-fähigen Webspace werfen kann, auf dem man keine Shell hat. Genau aus dem Grund sind Cheetah und ClearSilver für mich seinerzeit direkt gestorben und bis heute wiegt das Argument immer noch ganz ordentlich.

Y0Gi hat geschrieben:Genau aus dem Grund sind Cheetah und ClearSilver für mich seinerzeit direkt gestorben

Hallo Y0Gi!

Cheetah ist reines Python. Nur, wenn man möchte, kann man ein Modul mit einem in C geschriebenen Modul ergänzen. Damit wird Cheetah schneller. Es läuft aber genau so gut auch ohne dieses C-Modul. Bei mir ist Cheetah die ersten Tage komplett ohne dieses C-Modul gelaufen. Nur die Hinweise beim Kompilieren haben mich darauf gebracht, dass man Cheetah mit einem C-Modul noch schneller machen kann.

mfg
Gerold

Meine anderen beiden Topics hier habe ich im Titel als [gelöst] deklariert.
Darf ich das hier zu [gekidnapped] erklären?

wakko0815 hat geschrieben:Darf ich das hier zu [gekidnapped] erklären?

gerold: Hm. Entweder ist das mal geändert worden oder ich habe das damals tatsächlich überlesen. Dann war es aber *bestimmt* auch ganz undeutlich formuliert...

Y0Gi hat geschrieben:gerold: Hm. Entweder ist das mal geändert worden oder ich habe das damals tatsächlich überlesen.

Dann muss das aber wirklich lange her gewesen sein. In meiner Cheetah-Zeit (damals war Spyce 1.3 aktuell und Cheetah einer der wenigen TEs die es damals für Python gab) war das schon so, dass _namemapper optional war.