On 19 May 2012 22:36, anatoly techtonik <techto...@gmail.com> wrote: > Hi, > > Martin expressed concerns that using logging module with stderr output > can break web applications, such as PyPI. I couldn't find any proof or > denials for this fact, and it became a showstopper for me for further > contributions to PyPI, because clearly I can't write good code without > the sense of confidence. > > Here is the commit in question: > https://bitbucket.org/techtonik/pypi-techtonik/changeset/5396f8c60d49 > > I was redirected here from python-dev. So can anybody tell where are > those stdout/stderr fears coming from and how to dispell them? > (include in WSGI notes)
Part of this is likely going to be due to my deliberate action in early versions of mod_wsgi to prohibit reading from stdin and writing to stdout. This was specifically done to highlight that portable WSGI application shouldn't be working with stdin/stdout because in doing so they would break under a CGI/WSGI bridge written to conform to the example in the WSGI PEP. People don't like to change though and so a lot of people would say that mod_wsgi was broken and/or that one couldn't use stdout under Apache even though there was a configuration option there to remove the artificial limitation. Over time I saw this grow in to a bit of a myth that one couldn't even use stderr and started to see stupid things like people remapping both stdout and stderr to their own files or even /dev/null. Although this artificial limitation was removed some time ago with it being optionally enabled if you want to test WSGI application portability. Certain LTS Linux distros still ship ancient mod_wsgi versions where the limitation is the default. So I tried to enforce something to make people do the right thing, but people prefer to write crap code I guess. An old blog post where I bemoaned all this can be found at: http://blog.dscpl.com.au/2009/04/wsgi-and-printing-to-standard-output.html If the CGI/WSGI bridge example in the PEP had simple saved away original stdin/stdout and replaced them with an empty StringIO and stderr, this possibly would never have become the issue it was. My own CGI/WSGI bridge does exactly that now so as to allow people writing crap code to still run it on CGI/WSGI if they really need to: https://github.com/GrahamDumpleton/cgi2wsgi Graham _______________________________________________ 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