> Jeremy Hylton wrote:I don't think a large web programming toolkit belongs in the Python distribution. If anything, go the other way around and package a particular version of Python with this web toolkit.
Sure, both models have been successful in the past: PIL and Numeric are examples of "external, but only one" that have worked well.
Perhaps someone who took part in the discussion about what XML tools to include in the core Python distro could chime in with a little history?
The stuff started as an external package first, and still is an external package (PyXML). In my opinion the whole XML in the core story sucks. Not because the code in the core is bad, but because there's another package, PyXML, that completely overrides it in a non-bug-compatible way, meaning you now need to test your code that uses the XML core-code both with and without (various versions of..) PyXML installed. If this is to be done for any hypothetical web framework, let's please not do it the XML way... This is not due to a mistake; at the time the core was deliberately made to look for PyXML.
There are a ton of non-core XML frameworks around for Python, enjoying considerate popularity. The python 'xml' package is not the "one true way" to do XML with Python, and certainly doesn't enjoy anything near the popularity and buzz of Ruby on Rails, say. I don't see why the situation for any higher-level web framework should be different in this respect.
I'm also skeptical of a plan that sets out to build the one right way that everyone will use.
Well, then it's a good thing that's not what I'm asking for, isn't it? ;-) I think there's a place for entry-level (i.e., smaller than Zope) web app frameworks; the current confusion is about as helpful as having eight competing regular expression libraries, or six different "standards" for connecting to databases. Appointing a BDFWFOY is one
way to solve the problem (though admittedly less popular than denying it exists ;-). I'd welcome others...
What is exactly problem? That Ruby on Rails is taking mindshare away from Python? And so's PHP, and ASP, and Java, and so is Python from Java, and Zope from PHP, and so on. Could you explain why you consider Ruby on Rails to be different? Evidently you are of this opinion.
I do see a problem with Python web frameworks, but it's got little to do with Ruby on Rails, though I do think we can learn from its marketing success. My problem is that of islands; people are often sitting in the island of their own framework and making it hard for people on their islands to work together. I think there's far more code we can share between frameworks than we've been doing in the past. More sharing code and integrate various bits using standard ways is good as it allows us to join forces and not waste time reinventing wheels.
I think encouraging sharing, and setting up the circumstances to make sharing more easy (such as WSGI) is the only realistic way to reduce the confusion between Python web frameworks and make them start to evolve towards each other, which should also help marketing and reduce developer confusion during uptake.
In the Zope world, we've got islands too, in the form of CMSes built on top of Zope, such as Plone, CPS and Silva. We're currently in the process of trying to get off our islands and converge, helped by the transition to Zope 3 component technologies. I've been helping with that process, and it's fairly hopeful. So now I've started to set my sights a bit further and I'm trying to help Zope itself become less of an island within the Python world.
Regards,
Martijn _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
