On 22 October 2010 11:16, P.J. Eby <p...@telecommunity.com> wrote: > At 10:35 AM 10/22/2010 +1100, Graham Dumpleton wrote: >> >> Any one care to comment on my blog post? >> >> >> >> http://blog.dscpl.com.au/2010/10/is-pep-3333-final-solution-for-wsgi-on.html >> >> As far as web framework developers commenting, Armin at: >> >> >> >> http://www.reddit.com/r/Python/comments/du7bf/is_pep_3333_the_final_solution_for_wsgi_on_python/ >> >> has said: >> >> """Hopefully not. WSGI could do better and there is a proposal for >> that (444).""" >> >> So, looks he is very cool on the idea. >> >> No other developers of actual web frameworks has commented at all on >> PEP 3333 from what I can see. >> >> Graham > > Just out of curiosity, Graham, isn't PEP 3333 basically only a slight > modification to what you yourself proposed and implemented in mod_wsgi for > Python 3?
Correct, it is a bit more strict and changes wsgi.version back to 1.0. So, except for wsgi.version, Apache/mod_wsgi already technically conforms to it. I will be stepping a bit outside of the specification and having non CGI variables in environment from Apache configuration be treated as UTF-8 +surrogateescape however, with means to override the encoding. This though is going to be necessary because of capabilities of Apache and not an issue with WSGI specification. > My guess is that there's been no comment because there's really not much to > say about it. The most controversial thing about it was Python-Dev's > objection to modifying PEP 333 in place -- and that's the *only* reason why > it's a new PEP at all. I am not sure that it is that simple and that it is a done deal. Some people have been quite passionate about having bytes used in more places and the near silence from those people has me concerned that all is going to happen is that they will ignore PEP 3333 and another discussion will just erupt again later. It will be quite disappointing if Armin especially takes that stance and will not support PEP 3333 in Werkzeug, skip it and seek out an alternative. As I say in my blog post, ultimately it may not matter as PEP 3333 continues the WSGI name and so if they don't like it then what they come up with will have to be under a different name else it will be too confusing. At this point I can't see a future version based on PEP 444 being called WSGI 2.0, it is just going to be better to be clearly distinct in name after all that has gone on before. As such, Apache/mod_wsgi can be made to align with PEP 3333 for Python 3 and if anything else comes along later under a different name, then Apache/mod_wsgi will simply not implement it since it is specific to WSGI. If people want to somehow use Apache/mod_wsgi for it, they will have to use an adapter, if possible. Otherwise people will have to rely on other hosting mechanisms, be those other existing ones where author is prepared to support any new interface and not so fussy about naming inconsistencies or anything new that may come along. Thus I am just after some acknowledgement from involved parties that it is accepted that PEP 3333 is the way forward for WSGI for Python 3 and that it isn't just going to be ignored. Without that, as far as I am concerned we are still in limbo with only a little bit more mandate than before because of you having created the update as new PEP 3333, yet with no one pledging to accept it and use it going forward for major web frameworks. FWIW, what is the normal process for getting a PEP accepted as being the way of doing things so people all agree? Note that I haven't been reading python-dev list, so maybe there was some sort of agreement already expressed there which means PEP 3333 already has some sort of mandate and people just have to accept it, don't know. Graham _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com