[Web-SIG] A trivial template API counter-proposal
Phillip J. Eby
pje at telecommunity.com
Sun Feb 5 19:40:41 CET 2006
At 01:28 PM 2/5/2006 +0000, Alan Kennedy wrote:
>I've been dismayed over the last few days trying to follow the direction
>of this thread: it appears to me that something very simple has now
>become very complex.
On the contrary, the situation is and always has been very complex. It
only appears simple if you restrict your view to a particular narrow set of
use cases and ignore everyone else's. Python web frameworks are extremely
diverse in audience, needs, philosophies, and implementation. A "standard"
that doesn't take this into consideration is divisive, when what we need to
be doing is unifying. Having a standard that takes diversity into
consideration may be slightly more complex, but it allows *consolidation*
to occur over time.
The *real* additional complexity here is communication. Since each
framework has its own conceptual model of how things work, we've been
spending a lot of time just learning to understand each other. While time
consuming, it is absolutely a worthwhile effort if your goal is to get
everybody closer together. If we only discuss what we already have in
common, we are simply dividing the world into "us" and "them", preaching to
the choir and getting nowhere new.
That is why I've been fighting to hold off a mere rubber-stamping of a
non-web standard that happens to work for one family of frameworks; it
would be better for all of us if those use cases are handled as part of a
spec that brings everybody closer together.
That's not going to be as easy, true. It certainly hasn't been easy for
the people discussing it so far (myself absolutely included), and it
certainly won't be for the people reading the spec or implementing
it. However, not everything that is worthwhile is easy.
Developing WSGI was not easy, either, as I'm sure you recall. You and I
certainly argued a bit about iterators and file-like objects and such, and
it took a while before I understood all of your use cases and we were able
to resolve them in the spec. If you had given up on convincing me then, or
if I had given up on your use cases as "too complex", the spec would have
suffered for it. (And you wouldn't have gotten that prominent credit in
the PEP 333 "Acknowledgments" section. ;) )
>I can understand why the web-sig has fallen into the trap of tying a
>tmeplating API to its nice web standard, WSGI: all web applications must
>generate output. But web apps need to generate a wide range of media
>types, e.g. image/*, application/msword, etc, etc, etc.
And in many frameworks, it is the *template* that decides what media type
it is generating - and it may not even be outputting text or
unicode. Again, this is something that would be neglected by a text-only spec.
>This topic started with Buffet, the de-facto standard templating API for
>CherryPy. Buffet is just about textual templating, which is a good
>thing. That's why it's very simple, and is thus actually being used.
Which is precisely why we don't need to rush into blessing it as some kind
of web standard, when it doesn't have anything to do with the "web", as far
as I can tell. If I needed a plugin for pure text or XML templating (as
opposed to *web application* templates), or I were creating a pure text or
XML output generator, I would absolutely use the TG/Buffet API, no
question. It is 100% the right tool for the job, and the de facto standard
But I'm also 100% positive that it is *not* suitable to be declared a
Python *web* standard by itself: it's not about the web at all. The web
just happens to be where it's being used at the moment, and only in
frameworks where the use cases slot neatly together with it. Heck, just
look at the API documentation and see if you can find the word "web" or
even "request" mentioned on the page:
>I used that TAL implementation to generate the documentation for various
>things, usually just a flat set of HTML files in a directory: not a HTTP
>request in sight. Theoretically, I can envision a situation where I
>might want to swap TAL implementations for that offline generation
>process, meaning that it would be helpful to have a standardised API for
>controlling template cooking.
>Why should I have to use WSGI in that scenario?
You don't have to. As I mentioned many times in the discussion on
subtemplating, nothing stops template objects from offering *additional*
APIs besides WSGI. It's just that if we're making a *web* standard here,
then it should be possible for templates to do *web* things, not just play
with strings. Ergo, the string part of the API should be an optional
extension, or a standard part of the API but allowed to throw exceptions if
the template tries to do something that requires WSGI.
In contrast, I've listed numerous scenarios and use cases where providing
WSGI or something like it is absolutely essential. Nobody is proposing any
alternatives that would be part of the standard, as opposed to non-standard
I want to make sure that *your* use cases are supported by the spec. In
the absolute worst case scenario, you might have to do a little wrapping to
meet them. But I also want to support *my* use cases, and those of other
frameworks with similar ones. Those cases can't be supported without a
*web* API, which TG/Buffet does not provide.
We're all having this conversation because we want to achieve consensus so
we can achieve something in common, and use each other's tools. But we're
not going to have consensus while people's use cases are being left out
altogether. Nor will we have the greatest interoperability of tools if we
exclude entire classes of frameworks and templates from playing.
I believe that we can have a spec that allows for all the use cases being
discussed. Certainly, it will not be as simple as the TG/Buffet
API. However, if what you want is only the TG/Buffet API with some tweaks,
then you are saying you do not want co-operation with at least Zope and
Python server pages (which latter group includes at least users of Spyce,
Webware, Snakecharmer, and mod_python, as far as I can tell). And that
would seem to me to be a big enough subset of Python web users/developers
to say you don't want a Python web standard at all.
Why you'd want that, I'm not sure. Note that making it possible for people
to run their existing code in *your* frameworks means that they have the
option of migrating to your framework. But if you don't support that, they
can't. It seems to me that it is in framework authors' best interest,
then, to acknowledge the reality of these existing codebases and what will
be required to let them migrate to another system.
More information about the Web-SIG