The PyCon web summit is coming up in a few weeks. Questions for the panels have been requested and can be posted at:http://www.google.com/moderator/#16/e=1c9a94
Make sure you get your questions in.
Now, I am not on any of the panels, but it doesn't mean I don't have my own opinions on some of the questions.
As such, leading into the web summit I am going to try and select various questions and post here my own thoughts about them.
The first question I choose to get things rolling is:
"Should Python standardize Request and Response classes in WSGI (or another PEP)?" (http://goo.gl/mod/CNGn
If the question is whether we should standardise on high level feature packing request/response object such as WebOb/Werkzeug, then my answer is a definite no.
With a specification it needs to be something that is first simple, but also something that can be set and which isn't going to change very quickly and if possible rarely.
When we talk about high level request/response objects which embody a lot of feature functionality, it is inevitable that there will be calls that they evolve, sprouting new features etc.
I somewhat doubt that WebOb and Werkzeug are exactly the same as they were when first written and although we may have learnt a lot since then and may be able to do a better job this time around, one can't know how the web landscape will change and thus how those implementations will need to change.
So, keep such high level request/response objects out of the WSGI specification. If people want to separately agree to settle on using a specific 'implementation' of a request/response object, which is what you are really doing, then by all means do that, but keep that out of the WSGI specification itself.
That said, is there any need for any request/response like objects in WSGI. This is where I feel the answer could still be yes.
If this is done though, they should be very low level and the only purpose should be to help codify the protocol aspects of dealing with the WSGI interface and the mechanisms of implementing WSGI middleware and filters that so many people get wrong when they have to do it themselves. They should not be high level wrappers just to make accessing the request environ data and dealing with response headers easier.
Yes that is a bit vague, but I will have more to say about it in my state of 'WSGI 2' talk at the PyCon web summit.