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

[Alan Kennedy]

Graham,

I thought I'd reply, so that we'd get replies from everyone else to
tell me I'm wrong.

All your points are good common-sense stuff. I think that all of your
policies on stdin, stdout, and stderr are good, and are appropriate
for a WSGI environment running inside an Apache server.

Some small points.

> ..... one could actually write to sys.stdout directly as
> well since that is where the WSGI adapter writes it to anyway.

I think it's a good idea to redirect stdout, and to document in your
server/gateway documentation that you are doing so. I also think this
is a server specific issue.

> Anyway, it may seem good practice for a WSGI adapter to still prevent
> use of sys.stdin unless configured explicitly to allow it and even
> then it might only allow it if the server is running in a mode whereby
> it would work.

This should be a server-specific feature, that is documented.

> Finally, sys.stderr also presents problems of its own. Although
> wsgi.errors is provided with the request environment, this can't be
> used at global scope within a module when importing and also shouldn't
> be used beyond the life time of the specific request. Thus, there
> isn't a way to log stuff outside of a request and ensure it gets to
> the server log. One could try and mandate use of 'logging' module, but
> this isn't available in old versions of Python.

I don't think you need to worry about versions of python that don't
have the logging module. Strictly speaking, WSGI requires python 2.2,
because of iterators. So I think it's extremely unlikely that people
will be running WSGI apps on pre-2.2 VMs.

> What you need is for sys.stderr to be underlayed with thread
> specific log objects each with its own buffering mechanism that
> ensures that only complete lines of text get sent to the actual log
> file.

This is a server/gateway implementation detail.

> Yes one could simply ignore the whole issue, but I feel that a good
> quality WSGI adapter/server should address these issues and either
> lock things down as appropriate to protect users from themselves or
> ensure that using them results in a sensible outcome.

Given how much talk there is of the WSGI "environment", I think it's
good to raise these issues.

Regards,

Alan.