[Web-SIG] Declaring PEP 3333 accepted (was: PEP 444 != WSGI 2.0)

[Graham Dumpleton]

Can we not let the PEP 444 discussion side track getting PEP 3333
sorted out? This is exactly what has happened numerous times before
when we have been trying to sort out core issues of WSGI on Python 3.
And people wander why I get grumpy now every time this happens. :-(

So, where are we at? It seems the only real issue that needs to be
resolved is the correctness or otherwise of the CGI/WSGI bridge
example. Everything else could be left as is, even if dubious.

For the CGI/WSGI bridge I take it the issue is that for bytes need to
use the internal buffer directly. I don't see a need to flush the top
level stdout because nothing should be writing to stdout besides the
WSGI bridge and so it just needs to ensure it is consistent.

Is that the last thing or do I need to go spend some time and write my
own CGI/WSGI bridge for Python 3 based on my own Python 2 one I have
lying around and just do some final validation checks with a parallel
implementation as a sanity check to make sure we got everything? This
might be a good idea anyway.

Graham

On 5 January 2011 05:33, Guido van Rossum <guido at python.org> wrote:
> On Tue, Jan 4, 2011 at 7:48 AM, P.J. Eby <pje at telecommunity.com> wrote:
>> At 06:30 PM 1/3/2011 -0800, Guido van Rossum wrote:
>>>
>>> Would
>>>
>>>  sys.stdout.buffer.write(b'abc')
>>>
>>> do?
>>>
>>> (If you mix this with writing strings to sys.stdout directly, you may
>>> have to call sys.stdout.flush() first.)
>>
>> The current code is:
>>
>>            sys.stdout.write(data)  # TODO: this needs to be binary on Py3
>>            sys.stdout.flush()
>>
>> Should I be using sys.stdout.buffer for both, or just the write?
>
> For both.
>
> But the flush() I was referring to is actually *before* either of
> these, suggesting
>
> sys.stdout.flush()
> sys.stdout.buffer.write(data)
> sys.stdout.buffer.flush()
>
> However the first flush() is only necessary is there's a possibility
> that previously something had been written to sys.stdout (not to
> sys.stdout.buffer).
>
>> For the CGI example in the PEP, I don't want to bother trying to make it
>> fully production-usable; that's what we have wsgiref in the stdlib for.  So
>> I won't worry about mixing strings and regular output in the example, even
>> if perhaps wsgiref should add the StringIO's proposed by Graham.
>
> Not sure what you mean. Surely copying and pasting the examples should
> work? What are the details you'd like to leave out?
>
> --
> --Guido van Rossum (python.org/~guido)
> _______________________________________________
> 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
>