Being unjust

[Paul Boddie]

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