Pythonic way of web-programming

[Ian Bicking]

On Tue, 2003-04-15 at 07:01, A.M. Kuchling wrote:
> On Tue, 15 Apr 2003 02:30:49 +0100, 
> 	Andy Robinson <andy at reportlab.com> wrote:
> > Second, it has always seemed to me that there is a very well
> > understood model of a web app consisting of a controller, Request,
> > Response and a few other things, handled in very similar ways by Java
> > servlets, ASP and WebKit.  
> 
> I've speculated about adding a standard HTTP{Request,Response} type to the
> standard library, but even this seems unlikely because I doubt we can agree
> on what should be in it, or what naming convention to use.  (Quixote uses
> underscore_names, WebWare uses camelCase; whose users have to change all
> their code.)

One option would be to use an interface with adapters, where if say the
Quixote interface was used, Webware would have an adapter from that
interface to the Webware HTTP{Request,Response} interface... though I'm
not sure how interesting request and response object are.  Defining the
adapter may not be much less work than reimplementing it from scratch. 
But maybe not...

> There's also the inflexibility that comes with putting something in the
> standard library; the interfaces can't be changed without breaking existing
> users, so it's impossible to fix things.  cgi.py has lots of cruft in it,
> but I've never tried to clean it up because I have no idea what applications
> out there might be broken, so cgi.py stays crufty.  It's noteworthy that
> Quixote's upload handling only got really reliable when Greg Ward wrote his
> own upload parsing code and jettisoned use of cgi.py's code.

I don't think development of the standard library would do well at
syncing with development of something like this, at least not for a
while.  It seems to me like there's some questions about batteries
included anyway, that it makes development of new functionality
unwieldy.  It's more important in making something the canonical
implementation, and maybe that's achievable through other techniques.

> All this talk of unifying Web frameworks strikes me as pointless.  Different
> toolkits have different design principles and different goals; hoping for a
> unified one is like hoping Python and Perl will settle their differences and
> merge.  

I disagree.  Unifying with one model for building applications is not
likely, but there are a lot of places where the frameworks duplicate
effort without significant differentiation.  By identifying those we
could make a more robust, more easily distributed, more compelling
foundation for web frameworks.  

  Ian