> On Mar 25, 2016, at 05:01, Cory Benfield <c...@lukasa.co.uk> wrote:
> Given that gevent is keeping hold of its own reference to the environ, why 
> does gevent not simply wrap the environ dict in a class that implements this 
> functionality directly? In that manner, gevent can expose its own error 
> handling behaviour as desired, and continue to follow PEP-3333.

I did consider that, but didn't want to do that unless there were actual 
practical problems passing the same object that gevent references. Making a 
copy just to pass to the application adds additional time and memory 
requirements that are always nice to avoid in a server. 

> In fact, I believe this is exactly what PJ was getting at. The ability to 
> subclass the dictionary (in this case, to subclass it with one that hides 
> some keys on printing) is only useful to the entity that does the 
> subclassing, because there is no guarantee that the subclass will not be lost 
> somewhere else in the WSGI stack.

I looked at most of the middleware listed on the WSGI homepage [1], as well as 
a decent sampling of the packages identified as middleware on PyPI [2]. I 
didn't find any that passed a new environ on to the next application; they all 
seem to simply pass on the environ object as given to them. Now that's just a 
sampling so obviously it doesn't mean that such copying doesn't happen. But 
doing so eliminates the ability for lower middlewares to communicate with upper 
middlewares through the environ if they are more than one layer separated---a 
real-world example is setting `paste.expected_exceptions`---so practically 
speaking, I imagine it's quite rare.

> Because of that, I’m disinclined to want to widen the spec here. PJ’s 
> original analysis is right: allowing subclasses does not provide more utility 
> than disallowing them, but it does allow more bugs to creep in due to 
> inconsistent expectations. Better to have an object with a known set of 
> behaviours and have applications/servers wrap it in custom function.

I'm not sure I agree with that, but I can see the argument.

I started out by asking if there were any *practical* reasons not to pass a 
tiny dict subclass as environ, and when I was surveying existing middleware for 
this thread, I found a big reason: it turns out that WebOb's Request object 
*also* verifies that type(environ) is dict [3]. Given the popularity of WebOb 
and its derivatives like Pyramid, this is not a change gevent can make. We'll 
take a different approach.

Thanks again for all the great insights and discussion!


[1] http://wsgi.readthedocs.org/en/latest/libraries.html
[2] https://pypi.python.org/pypi?:action=browse&show=all&c=319&c=326&c=506&c=509
[3] https://github.com/Pylons/webob/blob/master/webob/request.py#L112
Web-SIG mailing list
Web SIG: http://www.python.org/sigs/web-sig

Reply via email to