Adrian Holovaty wrote: > Fuzzyman wrote: > > web.py has the great advantage that (allegedly) you can migrate apps > > from CGI to FastCGI, mod_python, WSGI. > > This isn't an advantage of web.py over other frameworks. You can do the > same thing with Django, because it has a WSGI backend; people run > Django with mod_python, FastCGI, etc. I believe the same flexibility > applies to TurboGears.
Generally, most frameworks now seem to offer *CGI, either via or in addition to WSGI. (One could uncharitably refer to WSGI as one of the *CGIs, I suppose.) Other server support generally seems to be a bonus, although I note that some WSGI implementations are attempting to support something more exotic than the *CGIs. Meanwhile, the main thing web.py has going for it is brevity - it otherwise seems like a fairly ad-hoc mash-up of various "full stack" components whose standard library inclusion would probably leave many other framework developers howling in protest (and not without reason, either). And given that some in the Python community squeal when software is made available to them under something other than a permissive MIT-style licence, I would honestly wonder what those people would make of web.py's licence. > > There are a few fundamental "philosophy differences" in web apps which > > makes it a bit of a religious war. This means getting something into > > the standard library is likely to be the cause of intractable > > discussions. *sigh* > > As much as I'd like to see the core bits of Django (which wouldn't > require a database or include other fancy high-level features) included > in the standard library, I do think it'd devolve into a religious war > inevitably. Here's my biased perception of the Web-SIG process, since any standardisation discussion supposedly starts there: first, everyone attempts to nail down request and response objects, reaching no particular consensus; then, the WSGI specification gets discussed for seven or eight months; then, everyone panics at the sight of the Rails juggernaut [1]; finally, I unsubscribe, but the archives seem to suggest a range of not-particularly-convincing attempts at moving the original cause forward. But with regard to the standard library, here's an interesting quote from a Web-SIG posting back in 2004: "I suspect that most web frameworks will bypass the 'cgi' module as much as possible; it's too messy to deal with and too difficult to clean up." [2] Sadly, most frameworks (in my experience in wrapping them up under a layer of cleaner functionality) do use the cgi module in some way or other, and I'd argue (and I believe always argued) that the best route forward would be to wean everyone off using that module directly in applications/frameworks and onto something more abstract and easier to use, possibly whilst tidying up the cgi module and making sure it works reliably for all the low-level parsing that it's still going to be responsible for doing. Sadly, WSGI hasn't addressed this issue at all, as far as I am aware: it just lets the frameworks battle it out at a marginally higher level. > A better goal, I think, would be to add some WSGI code to > the standard library -- for instance, code that runs a development > server for a WSGI-compliant framework, etc. Perhaps wsgiref: > http://svn.eby-sarna.com/wsgiref/ I think I probably underestimate the importance of WSGI, since its use seems to be quite widespread in the newer frameworks or mega-frameworks. However, WSGI is only a small proportion of the substance in the original Web-SIG mission: to make Web programming easier and more standard in Python. Over two years on (plus however many years the Python Web Modules list was being used), the standard library hasn't moved very much in that direction, creating a not insignificant obstacle to significant Python adoption, in my opinion. Paul [1] http://mail.python.org/pipermail/web-sig/2005-April/001205.html [2] http://mail.python.org/pipermail/web-sig/2004-March/000503.html -- http://mail.python.org/mailman/listinfo/python-list