Being unjust

[Kay Schluehr]

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