[Web-SIG] Future of WSGI

[Chris Dent]

On Nov 24, 2009, at 10:16 PM, Sylvain Hellegouarch wrote:

> Though it shouldn't be considered as a problem, the fact that  
> probably no existing framework actually use the raw dictionary  
> (there is, in almost all cases, a wrapping into a friendlier  
> object), one might wonder why keeping such a low level interface  
> rather than directly provide a higher level interface is a good  
> idea. After all creating those dictionaries for no good reason aside  
> from sending them to the next layer which will map them into a  
> WebOb, a yaro, a cherrypy request, or zope request, etc. seems  
> slightly pointless (I'm not versed into Python internals, but  
> doesn't it have also a cost of creating rather useless objects  
> repeatedly like that?) I know WSGI tries hard not to force into one  
> implementation but still...

I use the raw dictionary in TiddlyWeb <http://tiddlyweb.com/>, and I  
like it that way. I've resisted using existing frameworks exactly  
because they _do_ package the WSGI stuff up in what I perceive to be  
complex classes that obscure the overall flexibility and transparency  
presented by the WSGI dict.

I prefer middleware that just uses the dict that it gets, maybe making  
a few tweaks or additions and then passes it along to the next layer.  
This behavior is _exactly_ what makes WSGI great and useful.

Beyond that I just have a knee jerk reaction to the creation of  
gratuitous classes for something that is essentially a (very flexible)  
data structure.

I can (barely) relate to some of the complaints that start_response is  
a pain in the ass, but environ, to me, is not broken.

On start_response, I find that I can mess with it (replacing it with  
something else, usually) before I go deeper into a stack of WSGI  
applications is sometimes useful, so I would be disappointed if I lost  
that option.