> On Mar 24, 2016, at 11:09, Alan Kennedy <a...@xhaus.com> wrote: > > I don't see this relevant message in your references. > > https://mail.python.org/pipermail/web-sig/2004-September/000749.html > > Perhaps that, and following messages, might shed more light?
Yes, thank you, I did miss that thread. It does help shed some light on the issue. The two main arguments made seem to be that: 1) Creating subclasses of builtin objects is difficult and subject to breakage if you try to get too fancy. That's a fair point, and in the context of when it was written (Python 3.0 was still under discussion) it makes a lot of sense. 2) Middleware or the app can do dict(environ) and lose your subclass. Also true. But I think it's only particularly relevant if the WSGI implementation itself relies on the subclass to provide essential functionality that the PEP specifies (e.g., decoding bytes-to-str on key access). It was also mentioned that practicality beats purity and no practical use for a subclass was known. 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. Jason _______________________________________________ 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
