Python component model

[Paul Boddie]

Kay Schluehr wrote:
> Paul Boddie wrote:
>
> > 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?
>
> Paul, I do think the focus on the stdlib as it is right now is a bit
> misleading. The stdlib is basically the product of python-dev and the
> runtime developers also have maintenance responsibility. This shall and
> even must be splitted and shared as it is done successfully with
> application domains like Scientific Python.

Quite. But we're talking about supposedly well-established and widely
understood technologies here: the cgi module first appeared in 1994
(1995 in the library); that relative newcomer the Cookie module
appeared in 2000; BaseHTTPServer appeared in 1995; asyncore was added
to the library in 1999. And unlike various scientific computing
interest groups, those who use Web technologies are so broadly
dispersed across all kinds of other domains that I doubt that even if
GvR told everyone to take their Web modules elsewhere, there'd be
enough cohesion to have such an umbrella WebPython distribution.

> If an enterprise grows no
> one expects that one department is responsible for everything but here
> in the Python community Guido shall play Fidel Castro who cares for
> each module of each application developer ever written and its
> suitability for the stdlib and its alignment with the Python ideology.

Well, I don't want everyone's modules in the standard library, but I
think it makes sense for people to work on integrating modules into the
library that make it easier for them and others to then focus on other
stuff. What if the cgi, BaseHTTPServer and Cookie modules hadn't been
in the standard library? Whilst some people might regard the resulting
dearth of Web frameworks as a benefit, I think you'd see less activity
in that part of the community as a consequence.

> In my opinion Python shall grow up and organize the visibility of its
> products, its "portfolio", differently with Py3K. I agree with Fredrik
> that any decision towards a BDFL blessed webframework is premature and
> Guido already showed himself not much interest in making any decision.

But I don't want GvR to bless a framework. Consider his misunderstood
near-blessing of Django: it's almost nonsensical. Sure, Django
innovates somewhat in terms of describing the URL space, but there are
numerous people who don't like the templating or the ORM, so they
wonder if they just couldn't strip that stuff off and replace it, but
what are you left with? The bare platform, of course, which isn't worth
continually redeveloping for each megaframework, but that's what has
been happening over the last five years.

> Even if all kinds of components are available in the stdlib people are
> still looking for a RoR for Python and they do so not only for
> technical reasons but because they need a brand that can be justifed
> towards their team mates and project leaders.

True, and this is where a lot of the marketing Python discussion missed
the point, dwelling on the corporate acceptability of Python (ie. the
nod from the PHB) and ignoring the peer marketing effect (ie. some
colleague you get along with shows you something with a "cool" label
stuck to it). The Django and TurboGears projects have noticed this
phenomenon, in contrast to that other supposed "winner" of the
frameworks war (Zope), but I await the day when some other loudly
advocated technology emerges to expose Python's library weaknesses and
causes a similar reactive scramble amongst the interested parties of
that particular domain.

Paul