Comments on Graham Dumpleton: WSGI and printing to standard output.

Jon, the documentation at 'http://code.google....

2010-03-24T08:58:50.957+11:00

Jon, the documentation at 'http://code.google.com/p/modwsgi/wiki/DebuggingTechniques' mentions 'wsgi.errors'. The problem is that most frameworks hide it or it is non obvious how to get access to it. Even more, practically no one realises it is there and uses it and they always just use 'print' without even redirecting it. The 'wsgi.errors' stream is also not

Your suggested "portable" version of ...

2010-03-24T05:41:35.469+11:00

Your suggested "portable" version of

print >> sys.stderr, 'message ...'

is no more portable than the

print 'message ...'

than it's replacing.

It should be:

environ['wsgi.errors'].write('message ...')

For Google people that find this post in the futur...

2009-09-29T09:51:25.655+10:00

For Google people that find this post in the future, a cause of:

"sys.stdin access restricted by mod_wsgi" when moving from dev to production is because of an errant:

import pdb; pdb.set_trace();

Frustratingly, wsgi will throw an error from the NEXT line so you won't know that pdb caused it :-)

@Deron

The issue isn't to have the messages...

2009-04-04T19:48:00.000+11:00

@Deron

The issue isn't to have the messages logged to stdout to vanish, it is to get people to log them to the proper output stream, which is stderr.

One thing that both yours and the other response show is that even people who have some experience with Python development don't necessarily understand the greater issues around this. So, what hope is there for an absolute newbie

@garylinux

It isn't just debug code we are ...

2009-04-04T19:45:00.000+11:00

@garylinux

It isn't just debug code we are talking about here, it could be quite valid error messages which the application wants to log to the error log file, but people have wrongly used 'print' by itself to send it to stdout instead of stderr. Any WSGI framework library which used stdout for logging error messages would fail to work properly if used with a WSGI application hosted by a

What about providing a third option, a data sink, ...

2009-04-04T05:36:00.000+11:00

What about providing a third option, a data sink, like /dev/null. Provide a fake stdout file object that instead of raising an error or sending the output back to CGI, it just silently discards it. Maybe

WSGIRestrictStdin Discard

This could also help in those situations where you have to use a third-party module, that unfortunately sometimes does a stray print.

I am trying hard to figure out why I should care i...

2009-04-04T03:21:00.000+11:00

I am trying hard to figure out why I should care if my debugging code is cross system compatible. Its debugging code, written to run on the system I am working on right now.
It's going to be gone once the bug is tracked down.

The WSGIRestrictStdin Off
WSGIRestrictStdout Off
settings would be much more useful for developers if they would work in the .htaccess
Since (I

I'm sorry to see you having to make this change to...

2009-04-03T22:36:00.000+11:00

I'm sorry to see you having to make this change to appeal to the unwashed masses who can't read documentation. I will certainly turn that feature back on in mod_wsgi 3.0.

2009-04-03T22:35:00.000+11:00

This comment has been removed by the author.