2009/9/22 Mark Nottingham <m...@mnot.net>: > That blog entry is eleven printed pages. Given that PEP 333 also prints as > eleven pages from my browser, I suspect there's some extraneous information > in there. > > Could you please summarise? Requiring all comers to read such a voluminous > entry is a considerable (and somewhat arbitrary) bar to entry for the > discussion.
If you aren't willing to read the PEP to understand WSGI why are you even wanting to participate in the discussion in the first place? This is a quite detailed discussion about the future of the WSGI specification and not an IRC channel manned by ticket monkeys. :-( Graham > Thanks, > > > On 22/09/2009, at 4:36 PM, Graham Dumpleton wrote: > >> 2009/9/22 Mark Nottingham <m...@mnot.net>: >>> >>> So, what advice do you propose about decoding bytes into strings for the >>> request-URI / method / request headers, and vice versa for response >>> headers >>> and status code/phrase? Do you assume ASCII, Latin-1, or UTF-8? How are >>> errors handled? >>> >>> Are bodies still treated "as binary byte sequences", as per PEP 333? >> >> I thought my blog post explained that reasonably well. Ensure you read >> the numbered definitions. >> >> If you can't work it out from the blog, point at the specific thing in >> the blog you don't understand and can help. Don't really want to go >> explaining it all again. >> >> Graham >> >>> Cheers, >>> >>> On 22/09/2009, at 4:07 PM, Graham Dumpleton wrote: >>> >>>> 2009/9/22 Mark Nottingham <m...@mnot.net>: >>>>> >>>>> OK, that's quite exhaustive. >>>>> >>>>> For the benefit of those of us jumping in, could you summarise your >>>>> proposal >>>>> in something like the following manner: >>>>> >>>>> 1. How the request method is made available to WSGI applications >>>>> 2. How the request-uri is made available to WSGI applications -- in >>>>> particular, whether any decoding of punycode and/or %-escapes happens >>>>> 3. How request headers are made available to WSGI apps >>>>> 4. How the request body is made available to to WSGI apps >>>>> 5. Likewise for how apps should expose the response status message, >>>>> headers >>>>> and body to WSGI implementations. >>>> >>>> Same as the WSGI PEP. >>>> >>>> http://www.python.org/dev/peps/pep-0333/ >>>> >>>> Nothing has changed in that respect. >>>> >>>> Graham >>>> >>>>> Cheers, >>>>> >>>>> >>>>> On 22/09/2009, at 12:26 PM, Graham Dumpleton wrote: >>>>> >>>>>> 2009/9/22 Mark Nottingham <m...@mnot.net>: >>>>>>> >>>>>>> Reference? >>>>>> >>>>>> See: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> http://blog.dscpl.com.au/2009/09/roadmap-for-python-wsgi-specification.html >>>>>> >>>>>> Anyone else jumping in on this conversation with their own opinions >>>>>> and who has not read it, should perhaps at least read that. Also read >>>>>> some of the earlier posts in the numerous discussions this spawned at: >>>>>> >>>>>> http://groups.google.com/group/python-web-sig?lnk= >>>>>> >>>>>> as the current thinking isn't exactly what I blogged about and has >>>>>> shifted a bit as the discussion has progressed. >>>>>> >>>>>> Graham >>>>>> >>>>>>> On 22/09/2009, at 12:07 PM, Graham Dumpleton wrote: >>>>>>> >>>>>>>> 2009/9/22 Mark Nottingham <m...@mnot.net>: >>>>>>>>> >>>>>>>>> Most things is not the Web. How will you handle serving images >>>>>>>>> through >>>>>>>>> WSGI? >>>>>>>>> Compressed content? PDFs? >>>>>>>> >>>>>>>> You are perhaps misunderstanding something. A WSGI application still >>>>>>>> should return bytes. >>>>>>>> >>>>>>>> The whole concept of any sort of fallback to allow unicode data to >>>>>>>> be >>>>>>>> returned for response content was purely so the canonical hello >>>>>>>> world >>>>>>>> application as per Python 2.X could still be used on Python 3.X. >>>>>>>> >>>>>>>> So, we aren't saying that the only thing WSGI applications can >>>>>>>> return >>>>>>>> is unicode strings for response content. >>>>>>>> >>>>>>>> Have you read my original blog post that triggered all this >>>>>>>> discussion >>>>>>>> this time around? >>>>>>>> >>>>>>>> Graham >>>>>>>> >>>>>>>>> On 22/09/2009, at 1:30 AM, René Dudfield wrote: >>>>>>>>> >>>>>>>>>> here is a summary: >>>>>>>>>> Apart from python3 compatibility(which should be good enough >>>>>>>>>> reason), utf-8 is what's used in http a lot these days. Most >>>>>>>>>> things >>>>>>>>>> layered on top of wsgi are using utf-8 (django etc), and lots of >>>>>>>>>> web >>>>>>>>>> clients are using utf-8 (firefox etc). >>>>>>>>>> >>>>>>>>>> Why not move to unicode? >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Mark Nottingham http://www.mnot.net/ >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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/graham.dumpleton%40gmail.com >>>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Mark Nottingham http://www.mnot.net/ >>>>>>> >>>>>>> >>>>> >>>>> >>>>> -- >>>>> Mark Nottingham http://www.mnot.net/ >>>>> >>>>> >>> >>> >>> -- >>> Mark Nottingham http://www.mnot.net/ >>> >>> > > > -- > Mark Nottingham http://www.mnot.net/ > > _______________________________________________ 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
