Python component model

[Paul Boddie]

Fredrik Lundh wrote:
> Paul Boddie wrote:
> >
> > Well, that's just another way of saying that the scene remains
> > stagnant, because I don't see any winners.
>
> one, two, overflow ?  or are you saying that the lack of a monopoly means
> market stagnation, no matter how innovative the three big ones are ?

I've never maintained that a monopoly on how Web programming is done
would be a good thing. All I've ever tried to understand is why people
haven't tried to improve the generic support for Web programming (and a
whole load of other things) even to the level of something like the
DB-API. Take another area: all the time you get people asking how they
can conveniently access some Web site using a Python-based client, and
loads of people are coming up against issues with urllib, urllib2,
other libraries. Wouldn't it be good if the functionality were just
there in the standard library in a sane form? Or is the standard
library just a "grab bag" of demos these days?

[...]

> the standard library has never included non-trivial applications (and the three big
> ones are configurable applications, not libraries).  I'm not sure anyone has ever
> looked to the standard library for domain-specific applications or toolkits.

These non-trivial applications are just libraries with icing on. My
critique of the Web standardisation scene is that no-one is that
interested in cooperating on the libraries. Of course, that isn't a bad
thing if you choose your framework and find the facilities you need,
but when this is happening at such a low level in the "framework
stack", you needlessly fragment the scene. TurboGears and Django have
slightly different approaches, so if you're the sort of person who will
buy the shiny new TurboGears book (the one with the snake holding a
lightsabre, or something), you'll probably want to get the Django one
as well: great news for publishers, an own-goal for the common cause.

> > The thing is that people want a coherent message about Python and Web
> > programming.
>
> the message is out there, for anyone who wants to listen.  and they are listening.

And that message is...? All I see is the JPF, the PFJ and the JPPF.

> > why else do people still ask CGI-related questions on comp.lang.python?
>
> because CGI works well for simple applications where you don't want to waste
> any time whatsoever on hosting and deployment issues ?  heck, I spent parts of
> last weekend hacking on a light-weight CGI-based publishing system for portions
> of the effbot.org site, using Python 2.2 on Solaris.  loads of fun.

Quite. But I'd also suggest that people use the cgi module and
BaseHTTPServer because the former is a well-understood technology and
the latter is something you can read about in a couple of pages in the
library reference. Indeed, there are lots of BaseHTTPServer-related
projects out there, which is not particularly good news for deployment,
but then there's that big gap between the standard library and the
megaprojects that I mentioned.

> >> (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.
>
> I've never seen anyone besides Ian Bicking make that argument (and he's using
> WSGI plus a zillion ready-made building blocks when doing that).

You should read some of the articles linked to from wsgi.org, then.

Paul