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.
_______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
