At 10:33 AM 1/4/2011 -0800, Guido van Rossum wrote:
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).
Yeah, that sort of error checking seems out of scope for a PEP
example. If something was written to sys.stdout at that point, your
CGI was already broken. ;-)
> 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?
I meant that a production CGI gateway should handle various
boundary/error conditions. Graham was saying that a CGI gateway
should replace sys.stdout to avoid stray print()s causing problems,
and I consider that similar to saying, "what if somebody wrote text
to sys.stdout?" -- i.e., an error handling case that would be a good
idea in a production gateway, but which would obscure the common case
that the example is meant to illustrate.
_______________________________________________
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
