At 07:44 AM 12/21/2007 +0700, Brian Smith wrote: >In >fact, if that was done, there would be no reason to have wsgi.errors in >the first place.
There are other logging systems out there besides the Python logging module -- and some of them are better for their specific purposes. And the Python logging module doesn't give you any WSGI-level control over output. At least if you use wsgi.errors, you can have middleware that e.g. logs different parts of your application tree to different log outputs. >Furthermore, doing so turned out to be impossible anyway, since I can't >reliably redirect the output of every logger used by every third-party >package and every built-in package. Which just goes to illustrate the problem of using a global logging package that has only static context (which is one of my pet peeves re: the logging module). In my experience, you more want to be able to filter and route logs by component *instance* (e.g. which page of your web app is being rendered) than by code module (e.g. templating library vs. db library). Dividing up the logs by which module issued the message is a bug, not a feature. _______________________________________________ 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