[Web-SIG] Any practical reason type(environ) must be dict (not subclass)?

Jason Madden jason.madden at nextthought.com
Fri Mar 25 11:04:24 EDT 2016


> On Mar 25, 2016, at 05:01, Cory Benfield <cory at 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!

Jason


[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


More information about the Web-SIG mailing list