[Web-SIG] Request for Comments on upcoming WSGI Changes

Tue Sep 22 09:10:03 CEST 2009

2009/9/22 Mark Nottingham <mnot at mnot.net>:
> You're twisting my words; nowhere did I say i wasn't willing to read the
> PEP. What I did say was that a proposal can and should be made in less than
> eleven pages; I'd like to give my feedback, both because I use Python and
> because I have some interest in HTTP. However, my time is limited, and I
> already have a stack of other things to review on my desk.
>
> He who writes the most words does not (hopefully, for the sake of the Python
> community) win. I appreciate that you've taken the time to reason out a
> proposal, but the minutia of how you got to that place should not obscure
> the proposal itself.
>
> I'm not sure how to take your "ticket monkeys" comment, so I'll ignore it.

Sorry if I come across as being short.

None of us has time and this whole WSGI on Python 3.0 issue has been
going on since start of last year. Many of us are quite tired of it
all. I also don't personally know who you are, not recollecting seeing
your name in any past discussions. I am told though you were involved
back at time of original WSGI specification drafting, so apologies.

The ticket monkeys reference is just the allusion to a help desk. I
always think of what happens when people jump on IRC as being worst
case. That is, they treat people there like help desk staff who only
exist to serve them and not anyone else. So, you see people who have a
complex problem, pose a question in a single line. They then expect a
even more complex solution to there problem, usually expressed in one
line again.

There is a book I have been meaning to read called the 'Trusted
Advisor' which apparently goes on about providing assistance to others
as comparing the idea of being like a ticket monkey (help desk),
versus building a relationship with people in order to understand
their real issues and provide better solutions. Obviously being an
advisor rather than a help desk is ultimately going to be better for
the people needing help, but if the customer has the frame of mind
that you are just the help desk and don't want to put any effort into
the relationship, it is hard to try and be that advisor.

So, I felt a bit like a help desk in the way I interpreted your comments.

Graham

> On 22/09/2009, at 4:44 PM, Graham Dumpleton wrote:
>
>> 2009/9/22 Mark Nottingham <mnot at 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 <mnot at 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 <mnot at 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 <mnot at 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 <mnot at 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 at 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/
>>>
>>>
>
>
> --
> Mark Nottingham     http://www.mnot.net/
>
>