> On 24 Mar 2016, at 16:29, Jason Madden <jason.mad...@nextthought.com> wrote:
> Well, here's a practical use :) And the two points above do not apply to this 
> practical use, I think. (1) doesn't apply because `__repr__` is not going to 
> change and isn't fancy. (2) doesn't apply because gevent keeps a reference to 
> the environ its creates and passes to the app, so if middleware passes a new 
> dict(environ) on to the app, gevent's own error handling is still secure; 
> consider passing a SecureEnviron to the app a best-effort at 
> secure-by-default---if the user configures their application such that this 
> feature is disabled for part of the stack, that's on the application. No 
> feature of gevent will break, and it's better than not having the option at 
> all IMHO.

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.

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. However, if subclassing is only useful to you there is 
another alternative to the problem, which is to compose the environ dict into 
an object that applies the custom behaviour.

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.


Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Web-SIG mailing list
Web SIG: http://www.python.org/sigs/web-sig

Reply via email to