Evoque Templating v0.4 for Python 3.0
Support for Python 3.0
The same Evoque code base now runs on Python 2.4, 2.5, 2.6 and 3.0 -- possibly making Evoque the first full-featured template engine available for Python 3.0. Behaviour is identical on all four Python versions.Tighter lockdown of the in-process sandbox (restricted mode)
Primarily by an elaborated runtime scan of all expressions that are passed for evaluation. See the overview of how Evoque implements the in-process sandbox. And yes, do interpret this as an open challenge and invitation to try and break it , and, in the unlikely chance that you succeed, you may request anything you like as compensation, as long as it is beer ;-) Want a quick and dirty script to run devious templates?Revision of whitespace handling
Notably, reworked the meaning of the slurpy_directives=True mode to be more what most people seem to expect.Continued speed improvements
More minor performance optimizations. Evoque is fast, and is a real contender for the dubious but gratifying honour of overall fastest pure-python template engine. Included in the distribution are 3 benchmarks -- you can see the measured results on OS X 10.5 for Python 2.6.1 (as there is not much to benchmark against on Python 3.0) -- those numbers are a real tribute to python's conceptual integrity -- that rewards a straightforward implementation of a simple design with... amazing performance.
Labels: evoque templating python
posted by mario ruggier at 5:24 PM
2 Comments:
Hey
Ive enjoyed using evoque so far. I made the jump to python3.1 recently and decided to not use lxml, xslt, and my custom xsl extensions for a current project.
The limited number of templating solutions (2) for python3 lead me to try evoque and I like it very much.
To provide feedback, I otherwise would not have checked out evoque in 2.6 when compared to others for a couple reasons. Site polish and site organization.
Overall, site polish isn't bad and is totally preference, but i think there is room for minor css improvements to provide a more clean and elegant feel that it already possesses.
The real turnoff was site organization. The menu items on the left are pretty darn ambigious. If I click "usage", I get the clarification for where im going after I get there "..usage from within a python application"
I could go on about location of site template, and so on, overall I'd love to see a little more organization of the documentation, set clearly on the site.
A wishlist item in evoque would be to customize the $, much like the python Template class where you can specify another symbol to use, itd be great to do %{} instead of ${} for my jquery related script files. This would make it a little more diverse as a string templater, especially if you could specify a particular symbol per collection or domain. I briefly looked over the source to see what would be involved. Let me know if your interested.
Thanks for the comments, Daniel. Indeed, even now, almost a year later, there are still very few real templating systems for python 3, but this is certainly not Evoque's only strength ;).
Re: site polish, i'd gladly consider improvements to the presentation... do you have specifics of what you feel should be improved?
Re: site organization -- I can certainly empathize with having to suffer my choice of section labels e.g. "usage"! I chase brevity and clarity but it does not always work as I imagine for everyone... i guess the title hint that appears as you hover over the toc entry is not enough? Also, have you tried using the 1-page __all__ version of the doc? An easy improvement would be simply to use clearer labels / organization of the sections, do you have any suggestions? Another, more-work option, would be to generate a fully expanded toc, not only a toc that is expanded only for the currently visited branch -- this involves enhancing the underlying app used for the site.
Re: to do %{} instead of ${}. What is the precise requirement, to be able to replace the $ "escape" with % or with any character for an entire template, or for collection, or for a domain? How would the escape char itself be escaped, always by doubling it? I.e. when you want a literal % you would do %%?
Anyhow, I'd certainly be interested in any patch or outline of an implementation for this. I'd be open to integrating such a feature, but i'd be wary of any complexity added, and it must not introduce any special cases i.e. currently you can interchange ${expr}/$directive{expr} and ${%expr%}/$directive{%expr%} liberally e.g. for when expr needs to use a literal brace -- this should not change i.e. If the "escape" char used is % instead of $ then I should still beable to interchange %{expr} and %{%expr%}. Plus, if any such change goes in, it will have to be covered by the unit tests i.e. would need to replicate the current parsing tests for a parametrized "escape" character.
Chances are good that I will be doing a new release in the coming months. Id certainly be happy to consider this and other requests for new features. Feel free to email me any further material directly, if you prefer.
Post a Comment
Links to this post:
Create a Link
<< Home