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 -- http://mail.python.org/mailman/listinfo/python-list
