On 17 July 2010 22:30, <chris.d...@gmail.com> wrote: > On Fri, 16 Jul 2010, P.J. Eby wrote: > >> At 02:28 PM 7/16/2010 -0500, Ian Bicking wrote: >> There should be one, and preferably *only* one, obvious way to do it. >> >> And given that HTTP is inherently a bunch of bytes, bytes is the one >> obvious way. > > I think this makes sense. The thing which is assembling the WSGI > environment should do bytes and things further down the stack can > deal with it as they like. This aligns well with how I like to think > about such stuff: bytes on the outside, unicode on the inside. > > Given that app and frameworks developers can throw whatever keys > they like back into the environment, they can cope as they like.[1] > > What would be horrible is if there need to be multiple coping > strategies. Better to be able to say, "Oh it doesn't work? Try this > way to cope: remember it is bytes." > > However, unless I'm misreading the thread, the bytes issue isn't > really the bone of contention.
Actually it still is. There are still two competing camps. Some want text, some want bytes. The whole discussion started purely around basis of progressing the text based proposal. As usual, those wanting bytes step up and we get two interwoven discussions which if you don't know the history can be hard to follow. My personal opinion is that if you are going to go bytes everywhere, then you may as well throw out the complete WSGI specification as it stands now and fix all the other problems with the specification. This is on the basis that if people are going to have to rewrite their code a fair bit to handle bytes everywhere, you may as well structurally change the WSGI interface API as well to address other problems. Anyway, it seems to be moot at this point as some believe that bytes everywhere with Python language as it stands, plus state of stdlib would make use of bytes everywhere rather unmanageable, which is where ebytes comes in. Thus bytes everywhere doesn't sound like a short term solution and requires changes in Python itself to make it viable. Graham > People seem okay with bytes as long > as specifc points of pain are addressed, such as: > > * What's my PATH_INFO and SCRIPT_NAME? > * This server, which hosts, but is not, the WSGI environment builder > doesn't play well with this model. > * Some others I can't remember now. > > It seems then that perhaps a way forward is to say: Okay, it's gonna > be bytes. Now, given that, how do we deal with these other issues, > which perhaps can be recast and encapsulated to be considered > orthogonal to the bytes/not-bytes debate. > > Because we _know_ that any choice is going to come with costs, but > as things have dragged on, the lack of choice thus far is starting > to have as much of a cost as the costs that are wanting to be > resolved. > > [1] I not expecting or hoping for porting/migrating to Python 3 to > be simple/automatic/easy, but perhaps I'm cruel. > -- > Chris Dent http://burningchrome.com/~cdent/ > [...] > _______________________________________________ > 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 > _______________________________________________ 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