jinja2 of course!
Even the template system of Django is almost like jinja2

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.

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.

Doug Napoleone, there is new *fast* implementation for ZPT: http://chameleon.repoze.org/

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.

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.

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.

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.

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.

I've done a few implementations of Mustache ( http://mustache.github.com/ ) 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 ( http://code.google.com/p/spitfire/ ) which is loosely Cheetah-like, but is optimized pretty well (esp. if using psyco).