Skip to main content

Python: Mako

There's a new Python templating engine called Mako. It's basically a modern, more-Pythonic version of Myghty, which is a Python version of Mason. It makes sense to switch if you're already using Myghty. It also makes sense to use if you're a Python guy who wants to avoid learning something new and just wants to dump a bit of Python in the middle of some HTML.

I like Mike Bayer, Mako's author, but I prefer Genshi. Nonetheless, if Mike wants to go out and write another templating engine, more power to him!

However, my feeling is that Python needs another templating engine like I need another open source kernel!
<sarcasm>Yeah, thanks a lot Apple! Sure, Darwin's great! Too bad I can't use my airport card!</sarcasm>
Seriously, I'd be a lot happier if they kept Darwin and released Cocoa. Now, that would be progress.

*sigh* ;)

Comments

Ben Bangert said…
The other bit worth mentioning is that Mako is 10-16x faster than Genshi and about 4-7x faster than Myghty/Django. If you need speed, this definitely matters. While not everyone needs such speed, certain apps that are expected to have high loads and can't be cached definitely benefit from this.

I think its great that there's an excellent choice for XML-based templating (Genshi), and hope that Mako will be the cream of the crop for non-XML templating. There's certainly room for excellence in both categories, and I think Mako has a significantly more elegant feel to it than Cheetah has ever given me.
mike bayer said…
we know you prefer Genshi, but I know that you *love* those component-calls-with-content too :). Mako adds some new twists on them Myghty never had.
Anonymous said…
so JJ, what is it about Genshi that you prefer over Mako? Is it only the well-formed XML? Curious minds want to know.

(I'm now happy that I never bothered much to learn Genshi, since Mako seems to gel better with my brain... But maybe if I wait another month, I'll get another choice of templating languages ;)
Anonymous said…
These templating languages are highly code convenient --- which is nice. However, for separation between code and presentation (i.e., the holy grail) at the opposite end of the spectrum, you may want to look at StringTemplate:

http://www.stringtemplate.org/

which is available as PyStringTemplate 2.2 (as well as Java and C#). StringTemplate is very powerful and concise (in a functional programming style) yet avoids "leak"ing code into the presentation. Perfect for html.

FYI, the design of StringTemplate 3.0 is even more powerful and was driven by antlr 3.0 code generation (powerful templating) needs.

For example, StringTemplate has template inheritance (reuse of templates by inheritance) and ST 3.0 also has Template "regions" which were invented independently but match django's "blocks". I like to think of them as parameterized inheritance, where you can piecemeal substitute a particular sub-region/block with your custom sub-region/block while inheriting the rest of the template. The key is that you substitute a piece of an inherited template while reusing the template as a whole. Much more fine-grained than just template inheritance --- and therefore mighty useful for HTML header substitution, etc..

In any case, StringTemplate should be considered if looking for an industrial grade template engine where code and presentation separation is sought (or required).
jjinux said…
> The other bit worth mentioning is that Mako is 10-16x faster than Genshi and about 4-7x faster than Myghty/Django. If you need speed, this definitely matters.

Agreed

> While not everyone needs such speed, certain apps that are expected to have high loads and can't be cached definitely benefit from this.

Agreed

> I think its great that there's an excellent choice for XML-based templating (Genshi), and hope that Mako will be the cream of the crop for non-XML templating. There's certainly room for excellence in both categories,

Agreed
jjinux said…
> we know you prefer Genshi, but I know that you *love* those component-calls-with-content too :)

Hey, no fair hitting me at my weak spots ;)
jjinux said…
> so JJ, what is it about Genshi that you prefer over Mako?

1. I like the inverse inheritance thing via includes. Mako can do the same type of thing.

2. I like the XPath thing. This is perhaps the biggest selling point for me. I have to write the common look-and-feel for multiple apps. Using XPath to tweak any part of the look-and-feel for any given page is quite powerful.

3. I like the way Genshi is really smart about escaping HTML that I don't write myself. I'm tired of the XSS problem, and Genshi makes a lot of the problem go away.

4. I like the fact that Genshi has three syntaxes: something like Nevow, something like Cheetah, and something like Kid. I can have my cake, with the frosting, and eat it too :)
jjinux said…
> These templating languages are highly code convenient --- which is nice. However, for separation between code and presentation (i.e., the holy grail) at the opposite end of the spectrum, you may want to look at StringTemplate:

I think Genshi provides exactly the amount of separation that I feel is best. This is a matter of engineering taste.

Popular posts from this blog

Ubuntu 20.04 on a 2015 15" MacBook Pro

I decided to give Ubuntu 20.04 a try on my 2015 15" MacBook Pro. I didn't actually install it; I just live booted from a USB thumb drive which was enough to try out everything I wanted. In summary, it's not perfect, and issues with my camera would prevent me from switching, but given the right hardware, I think it's a really viable option. The first thing I wanted to try was what would happen if I plugged in a non-HiDPI screen given that my laptop has a HiDPI screen. Without sub-pixel scaling, whatever scale rate I picked for one screen would apply to the other. However, once I turned on sub-pixel scaling, I was able to pick different scale rates for the internal and external displays. That looked ok. I tried plugging in and unplugging multiple times, and it didn't crash. I doubt it'd work with my Thunderbolt display at work, but it worked fine for my HDMI displays at home. I even plugged it into my TV, and it stuck to the 100% scaling I picked for the othe

ERNOS: Erlang Networked Operating System

I've been reading Dreaming in Code lately, and I really like it. If you're not a dreamer, you may safely skip the rest of this post ;) In Chapter 10, "Engineers and Artists", Alan Kay, John Backus, and Jaron Lanier really got me thinking. I've also been thinking a lot about Minix 3 , Erlang , and the original Lisp machine . The ideas are beginning to synthesize into something cohesive--more than just the sum of their parts. Now, I'm sure that many of these ideas have already been envisioned within Tunes.org , LLVM , Microsoft's Singularity project, or in some other place that I haven't managed to discover or fully read, but I'm going to blog them anyway. Rather than wax philosophical, let me just dump out some ideas: Start with Minix 3. It's a new microkernel, and it's meant for real use, unlike the original Minix. "This new OS is extremely small, with the part that runs in kernel mode under 4000 lines of executable code.&quo

Haskell or Erlang?

I've coded in both Erlang and Haskell. Erlang is practical, efficient, and useful. It's got a wonderful niche in the distributed world, and it has some real success stories such as CouchDB and jabber.org. Haskell is elegant and beautiful. It's been successful in various programming language competitions. I have some experience in both, but I'm thinking it's time to really commit to learning one of them on a professional level. They both have good books out now, and it's probably time I read one of those books cover to cover. My question is which? Back in 2000, Perl had established a real niche for systems administration, CGI, and text processing. The syntax wasn't exactly beautiful (unless you're into that sort of thing), but it was popular and mature. Python hadn't really become popular, nor did it really have a strong niche (at least as far as I could see). I went with Python because of its elegance, but since then, I've coded both p