Unification of logging in Python's Standard Library

[Robin Becker]

In article <vk5kc9g9uqj038 at news.supernews.com>, John Roth
<newsgroups at jhrothjr.com> writes
>
>"Matthew Barnes" <matthew at barnes.net> wrote in message
>news:3a8e83d2.0308191655.7a82881b at posting.google.com...
>
>> I will say that unittest is what motivated me to suggest this in the
>> first place, since I'm working on a testing framework that is
>> attempting to take advantage of both the unittest *and* logging
>> modules.  Perhaps a new TestRunner class that uses logging
>> (LoggingTestRunner?) might coexist with the default TextTestRunner.
>
>Perhaps you could tell us a bit more about this? My usage of
>unittest is (relatively) pure XP/TDD - I expect all of the tests
>to pass except the last one I worked on, and when they don't,
>I swat it immediately. Consequently, I don't see any need for
>logging anything.
>
>John Roth
>
>>
>> Matt
>
>
We currently have cgi scripts that implement logging by wrapping a
dispatch function. We test everything before going live, nevertheless we
still get errors in production and the logging is then invaluable. A
typical case is that of inconsistencies accidentally introduced into the
back end data base which the end users control; this is not exactly our
error, but it causes failures in our code.

On a different point we have different logging for testing in our office
and on the client's staging, testing and production machines. Typically
we use files for simple testing, but on the client production machines
we have a single database which collects all the errors from several web
facing servers. This requires that our code recognise its location (we
use presence of files called LIVE etc) and I wonder how other people
handle this terrain recognition problem?
-- 
Robin Becker