[Web-SIG] Direct use of sys.stdout, sys.stderr and sys.stdin in WSGI application.

[Graham Dumpleton]

Thanks for all the input, gives me some things to think about.

On 23/03/07, Ian Bicking <ianb at colorstudy.com> wrote:
> Graham Dumpleton wrote:
> > In the case of sys.stdout, do people see it as being at least good
> > practice, if not required by specification, that the WSGI adapter
> > should ensure that sys.stdout cannot be written to directly or by
> > using 'print' from a WSGI application. Thus, in a CGI adapter it would
> > do something like:
> >
> >   import sys
> >
> >   class dummystdout:
> >     def write(self, *args):
> >       raise IOError("WSGI prohibits use of sys.stdout.")
> >     ....
> >
> >   def run_with_cgi(application):
> >     ...
> >
> >     stdout = sys.stdout
> >     sys.stdout = dummystdout()
> >
> >     ...
> >
> >     def write(data):
> >       ...
> >       stdout.write(data)
> >       stdout.flush()
> >
> > In other words, it saves a reference to sys.stdout for its own use and
> > then replaces sys.stdout with a dummy file like object that raises an
> > exception if written to in any way or flushed.
>
> As an avid use of "print" for debugging, this would bug me.  I would
> prefer just avoiding the CGI case where stdout goes to the client, and
> otherwise saying that the server should try to put stdout output
> someplace where it can be read.  But it could very well be a console,
> not necessarily a log file.  Or the same log file as stderr, or...
> something.

Although using 'print' is handy. The reason I  was making sys.stdout
off limits and not just merging the output with sys.stderr, is that at
least one Python web framework hijacks sys.stdout for their own
purposes so that people can use 'print' to generate the actual content
of the response. The package that does this is web.py
(http://webpy.org/). Not sure if there are others which do this.

Graham