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

[P.J. Eby]

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.