Paul Boddie wrote: > 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.
Funny reading ! I don't want to know what happens when the BDFL gets hitten by a bus ;) A pro pos BDFL. Citing his recent blog entry on Artima seems to indicate that "religious wars" will sooner or later be inevitable: "I actually don't think Google uses Zope (contradicting my own statement above! :-). I just spoke to Mark Shuttleworth who also expressed concern about the lack of a "de-facto standard" Python web framework. I hope to be working on this issue somewhat, but it'll take a long time, and I doubt it'll involve open-sourcing Google code that is curently proprietary." From: GvR: Re: Python Status Update Posted: Jan 13, 2006 4:30 PM http://www.artima.com/forums/flat.jsp?forum=106&thread=143947 -- http://mail.python.org/mailman/listinfo/python-list