Python component model

[Paul Boddie]

Fredrik Lundh wrote:
> Paul Boddie wrote:
>
> > Meanwhile, the Web programming standardisation scene remains
> > stagnant.
>
> Aw, come on.  The Python web programming standardisation wars are over, for now.

Well, that's just another way of saying that the scene remains
stagnant, because I don't see any winners.

> There's Django, and there's TurboGears, and there's Zope 2/3, all with slightly different
> approaches, and slightly different target audiences.  Unless you're doing really odd things,
> one of these will be more than good enough for your application.

I didn't deny that various frameworks would be good enough for various
things (indeed, I didn't even mention them), and I personally think
that Django seems like a decent enough solution, even though it (or its
documentation) focuses on ORM+RDBMS-based applications - a focus that
wouldn't suit a number of applications I've worked on.

The thing is that people want a coherent message about Python and Web
programming. It doesn't have to be "use only this and nothing else" but
it should help them make a good but quick decision. For a long time
people expected to get this coherent message by looking for solutions
provided with the Python distribution itself - after all, the standard
library has provided other useful "batteries" over the years - but all
we had was the cgi module and some barely maintained servers. Indeed,
the standard library looks pretty incoherent itself these days.

But there's a huge gap between what's on offer via the standard library
and the most popular full-stack frameworks, and the choice of starting
with WSGI middleware or swallowing Zope development whole, for example,
must be something of a demotivator for newcomers - why else do people
still ask CGI-related questions on comp.lang.python? What's interesting
is that one of the Django pioneers advocated better standards way back
in 2003 [1], possibly indicating a preference for the "rising tide
floats more boats" philosophy that would help Python itself become a
more popular tool for Web development, rather than some framework doing
a Zope and, in a few years, having its community members argue amongst
themselves about why Python developers don't like them any more. It'd
be interesting to hear whether the same attitude still holds sway after
Django's more recent success.

> (as for WSGI, it's plumbing. You can of course build fun things from spare parts and
> plumbing, and there are really interesting things going on in certain research labs, as
> usual, but if you want turn-key stuff, pick one of the big three.)

After seeing WSGI being elevated to non-plumbing (since plumbing is
just stuff that helps other stuff to work, not something you mess with
on a daily basis), I think the current strategy with respect to
"floating more boats" is to pretend that WSGI is all you need. In which
case, we might as well start looking at documentation like this
instead...

http://www.erlang.org/doc/doc-5.5.1/lib/inets-4.7.5/doc/html/mod_esi.html

Paul

[1] http://mail.python.org/pipermail/web-sig/2003-October/000003.html