Re: Any practical reason type(environ) must be dict (not subclass)?

--===============4525226684012361050==
Content-Type: multipart/signed; boundary="Apple-Mail=_7FFDF914-39EB-49D4-9C38-023BFE323269"; protocol="application/pgp-signature"; micalg=pgp-sha256


--Apple-Mail=_7FFDF914-39EB-49D4-9C38-023BFE323269
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On 24 Mar 2016, at 16:29, Jason Madden <[email protected]> =
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=E2=80=99m disinclined to want to widen the spec here. =
PJ=E2=80=99s 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


--Apple-Mail=_7FFDF914-39EB-49D4-9C38-023BFE323269
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJW9QyQAAoJEHD+F/imQ+FbKXQP/23TIQwJohgOc2rHJF0XlJyQ
LiE2zHLLVe+rbAj9hUfNE+BVmp4+jEUWRjUlK/W3ipuqbmluxkepC5ivdknlj3KI
O6sHVQqXgQErRBxZi3is/Ze10K8ujTC4Ig3jFGKqoCSf6QKM/OUBuoFNXyfIeWfS
T6IlAnHGyweTathSUI7cAhUij8qY/A0PZj/KOffBXztOOEV4b4D3C6h4ect9w+ET
Iahnif37o1pv2IuU5tIY9XKtujvqzfySSHljQHuTWQfxcdqa8boLzRmV3ThWFYAq
Jn3fJKV0yGDiUoucEskarPL7NbMCzykhSQ0R1kn4Jucoo+urcKUCQc/pdv+IYag0
jDA1vyPS1u6BIEQMkGJKiw+W7zS7FlzDxn2gdkYVslE1QXEOh9SRFP5HdXzzNDHO
x5hKlzw8qNRn8FuGNdUqetdWps2kfbDo3Dbb/R8/fg2GUHv//W5tMzC7eHhfR2W+
SfzmIufe7checYayXQ6j25cW6orcDuAyiUbOYHiu7q+WJRP4b/XWvLulMQMfxbuG
W+K6S4UG+qUDIhrpqvGYFf5Gk8+x8j75k3Uf/pzIE8K32lQnXluE3hWRl1HYL1UX
0PlSEoIBMQ7cK6OBSpf84foa9XjBLwxjsqPJQrvBLwN82XIo54PVS1gGc28/f+CL
rcFO65FwIThCbBVmNtaP
=Jaq2
-----END PGP SIGNATURE-----

--Apple-Mail=_7FFDF914-39EB-49D4-9C38-023BFE323269--

--===============4525226684012361050==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Web-SIG mailing list
[email protected]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: https://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org

--===============4525226684012361050==--