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 <gu...@python.org> wrote: > On Tue, Jan 4, 2011 at 7:48 AM, P.J. Eby <p...@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@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
