empy 1.3 -- Embed Python in template text as markup

Erik Max Francis max at alcyone.com
Tue Aug 27 02:01:27 CEST 2002

Neil Hodgson wrote:

>    I'm not convinced myself and am pushing the idea out mostly for
> discussion and thinking about. Don't bother with an implementation
> just
> because of me.

Well, it's straightforward and isolated enough that I went ahead and
implemented it with the @: ... : ... : notation; it will be included in
the next version of empy.

>    Having full Python functionality is very useful. I have several
> projects
> that use some form of templating.

Absolutely.  I had previously been using m4 for doing my Web templating
stuff -- at first it was fun, since m4 is such a strange environment,
but eventually it became very tedious to do even simple things.  The
straw that broke the camel's back was when I started using Python
scripts for cataloguing and organizing systems, I'd have to write out
the databases in tables of m4 definitions that could be utilized by the
m4 scripts themselves.  Eventually this became almost laughable, since I
was using an extremely easy and convenient language to organize things
around an extremely awkward and difficult one.

> It is tempting to change them over
> to empy
> although it would be extra effort for something that already works
> well
> enough. I'll probably wait until a new project needs templating and
> then use
> empy for that.

Great, I'm glad to hear it.  Let me know how it turns out.

>    I couldn't see any way to quote markup characters. A quoting
> mechanism
> could lessen problems with particular markup character choices such as
> the
> '>' you mention above or if a @() expression were to use ')'.

One of the core ideas behind empy is that blocks of code (whether
expressions or statements) should be completely untouched by the empy
processing system, so they can be sent directly to an interpreter.  So
(hopefully) the idea is that all the empy annotations should be
unambiguous.  The choice of @< ... : ... > for the protected evaluation
(evaluate left-hand expression; if it throws a non-SyntaxError, evaluate
and expand with the right instead) was just pure oversight on my part. 
As I said earlier, I've rolled this and conditional evaluation into the
@( ... ) syntax; the protected evaluation mechanism would simply be
accessed with @( ... $ ... ) now.

 Erik Max Francis / max at alcyone.com / http://www.alcyone.com/max/
 __ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE
/  \ There is nothing so subject to the inconstancy of fortune as war.
\__/ Miguel de Cervantes
    Church / http://www.alcyone.com/pyos/church/
 A lambda calculus explorer in Python.

More information about the Python-list mailing list