> 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. Cory
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: https://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
