> 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 

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 

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

Reply via email to