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
9 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.
Yes, it just works, that's kind of why there has been really very little reason to put out any updates. The past few months saw going thru a serious physical move, adding to why I have been doing so little on this. But, as I mentioned above, there are a few things i'd like to make even simpler, break off decodeh module, put the source code onto a dcvs site to make it easier for others to participate, etc. Are you thinking of any enhancement in particular?
What context have you been using evoque with? A framework other than those mentioned in
Integration with external systems?
I have found this great templating system after failed to find an elegant approach to use dictionary directly in django template. In evoque it just works, all as I expected.
And to some extend you can even write modularized html templates like in programming -- site-bars and nav-bars are resides in a lib.html and in base.html you just evoque them.
It is great and thank you!
Hi Mario --
I'm just getting into Python and templating and I'm excited about having found evoque.
One question - does qpy 1.8 really work with Python 3.3? (I know it's not your project, but you recommend it so I'm wondering if you still recommend it for 3.3).
The reason I ask is there are a lot of C build errors with 1.8 and looking at the sources, it doesn't appear to be comptible with Python 3.3.
Thanks
Doug
Hi Doug,
thx for your comment, have asked the maintainer of qpy, David Binger, about issues with Python 3.3, and he says that Python 3.3 has changed the implementation of strings, and requires some adjustments to qpy that have not yet been released.
Until an update of qpy for py 3.3. is available, I can suggest to, for now, either use Py with 3.2 or else try running with the head of evoque src (from the source at https://bitbucket.org/mr/evoque) as this contains a new "quoted" sub-package that also contains a python-implementation equivalent of the xml() quoted-no-more infectious string class that is what is used in qpy (that implements it in C of course, so performance will be different).
All you'd need is to specify the evoque.quoted.xml.xml class directly as the quoting parameter wherever it is supported (e.g. on domain) as explained here: http://evoque.gizmojo.org/howto/quoted-no-more/ --once an updated qpy is available, all you'd need to do is switch quoting back to use the xml class from qpy.
Hope that helps, mario
I have to expose my noobness now :(
The project I'm on is going to try and embed the Python interpretter in our app, and use evoque for templating. What I'm hoping to accomplish is put something like ${getTitle(4)} into a template. So far it's not going well.
getTitle is a function on an imported object. So I'm able to:
import myModule
myModule.getTitle(4)
template.evoque()
That works.
Is it possible to put the getTitle call into the template itself? I know the sandbox is important, but the import happens before the evoque call (in the main 'app'), so I was hoping to get lucky.
Any advice?
Thanks for a great tool.
if I understood you correctly, if you wish the getTitle callable to be available in the template execution namespace throughout the domain, you may simply set up the domain with something like:
domain.set_on_globals("getTitle", getTitle)
and if you wish it to be available only for certain cases, you may pass it explicitly on each desired template evocaton:
template.evoque(getTitle=getTitle)
One more question Mario (well, for now!). Using your last idea (which works wonderfully) I'm trying to figure out how to essentially assign a variable, which I know isn't allowed.
What I'd like to do is:
$if{len(functionCall()) != 0}
[h1]header[/h1]
$for{(var1, var2) in functionCall()}
... output var1 and var2
$rof
$fi
functionCall() in this case is expensive, so I'm trying to figure out how to output the header only where there will be data below it. Normally assigning a variable would do it, but I don't think that works in the sandbox.
Any ideas or do I just need to call that function twice?
Thanks for a great module.
Post a Comment
<< Home