E pur si muove

Templating engine in python stdlib?

Monday, August 09, 2010

I am a great proponent of the python standard library, I love having lots of tools in there and hate having to resort to thirdparty libs. This is why I was wondering if there could be a real templating engine in the stdlib some day? I'm not a great user of templates, but sometimes string.Template is just not good enough and real templating would make things a lot more readable.

Not being a great templating user I don't know how the world of templating looks. Is there a template engine out there which would be a candidate to move to the stdlib? Or do most people think this is a stupid idea? Or maybe this has been discussed before and I didn't find the discussion?


Doug Napoleone said...

The real issue is having the project (whatever it is) tied to the python release schedule. This has been the deciding factor for a number of projects which would be good for the standard library. The ones which the greatest adoption usually have release schedules around 6-9 months, and many down stream projects count on getting fast turn around on those releases or drawing from the repo directly. Things which you don't get with the stdlib.

For the most part the project needs to be very mature, and template engines thus far are either mature and tied to a framework or young and untethered. The zope template engine is insanely mature and stable for instance, but not really separable. Jinga2 is fantastic, but is still young and improving at a rate faster than the stdlib.

The same thing happened with elementtree. It was talked about inclusion for a few years before things settled down enough to bring it in, and even then many people thought it was too soon.

Ian Bicking said...

Tempita (maybe stripped down a little) might be reasonable, but more as a string.Template alternative (or a str.format alterative) than a competitor for Jinja2. I think there's room for a templating language that isn't for constructing whole HTML pages, but there's not a lot of options that are simple enough.

Unfortunately templating languages don't really integrate all that well with the Python. I've thought about what it might mean to compile to actual Python bytecode (without source code generation), but it's kind of complicated. Could be fun though.

Anonymous said...

Doug Napoleone, there is new *fast* implementation for ZPT:

Hanno Schlichting said...

I think there's too many different template engines and languages out there, without any one of them having a major mindshare behind them.

The "old timers" are zope.tal (Zope Page Templates), which has a new standalone and fast implementation with chameleon.zpt. Genshi and it's fast reimplementation in chameleon.genshi (with some of the more dynamic features not being supported). Cheetah and it's fast reimplementation Spitfire used by Youtube. Then there's Myghty and the fast and new Mako. Django has its own language. Then there's Smarty and Jinja2. And the list goes on and on with more of these.

All of these have different styles, different features and different integration levels with other types of software. I cannot see any criteria by which you could choose one of these over any of the other ones. And it seems innovation in this area is still high and new projects are still popping up all the time.

Anonymous said...

Maybe a simple interface would suffice to make life easier. We could have a render method in the stdlibthat takes a file-like and a mapping:

>>> from template import render
>>> render(template_file, data)

it would use string.Template by default, but would allowing people to configure another template engine
to be used.

DasIch said...

I don't think Armin would like to see Jinja2 in the stdlib at all and I wouldn't either. Most applications don't need such a powerful template engine and if you need one there are a lot of different flavors to choose one.

A solution in the stdlib requires the library to be basically dead and encourages the use of "bad" (read outdated) libraries in the future, a perfect example would be ConfigParser which is truly horrible compared to other solutions like ConfigObj or even something I could write in half an hour.

mike bayer said...

Lets consider today, we put Cheetah in 10 years ago. Considering how large and opinionated Cheetah is, how would we feel about that today ? Jinja is a much more modern system but I think its still in the "Cheetah" category of stdlib choices. The stdlib needs to have things that are very small and stable.

My vote if any would be Tempita though the other day we had a request for a sandbox-friendly template language (i.e. doesn't allow execution of Python code), was surprised that even Tempita doesn't suit that need. Personally I'm fine with dict-interpolated strings.

Unknown said...

Heh, I know all the restrictions of the stdlib. Which is why I wondered if there was a suitable templating engine. It appears there isn't (yet).

And I think things can still evolve in the stdlib, they just need to be at a suitable and calmer stage in their life (no need to be "dead"!).

I'm not sure how Tarek's idea could work, my main problem is that string.Template is too simple. The code would be a lot more readable if there where conditionals and loops in the templating language.

Cheers for the pointers to Tempita btw.

Benjamin Listwon said...

I've done a few implementations of Mustache ( ) which works nicely if you have a view object (dict) and want to pair it with a template. To make it really sing, you need to do some work around the idea of partials as well as some optimizations in the matching of tokens, etc. But I've gotten it down to 160ms for a 10K row by 10 column html table with substitutions.

Not sure if it is the greatest, but it is a good starting point, and enforces the separation of logic and template (until some wiseguy mucks up your parser).

Also, there is spitfire ( ) which is loosely Cheetah-like, but is optimized pretty well (esp. if using psyco).

New comments are not allowed.

Subscribe to: Post Comments (Atom)