[Python-Dev] Using logging in the stdlib and its unit tests

[Nick Coghlan]

On Wed, Dec 8, 2010 at 10:09 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Tue, 7 Dec 2010 23:45:39 +0000 (UTC)
> Vinay Sajip <vinay_sajip at yahoo.co.uk> wrote:
>> Antoine Pitrou <solipsis <at> pitrou.net> writes:
>>
>> >
>> > I thought "error" and "critical" messages were logged to stderr by
>> > default? Isn't it the case?
>> >
>>
>> Only if you call basicConfig() or use the logging.debug(), logging.info(), etc.
>> module-level convenience functions (which call basicConfig under the hood).
>
> Why wouldn't it be the default for all logging calls ? Such special
> cases don't really make things easy to remember.

Indeed - I was very surprised to find just now that calling
"logging.warn('Whatever')" is not the same as doing "log =
logging.getLogger(); log.warn('Whatever')".

Adding a NullHandler isn't the right thing to do - the behaviour I
would want for any standard library logging that hasn't been
explicitly configured otherwise is to do what the root logger does
under basicConfig(): debug() and info() get suppressed, warn(),
error(), critical() and exception() go to stderr. It seems to me like
that would be more useful default behaviour in general than emitting a
warning about not finding a handler.

So my suggestion would be:
1. In the absence of a "config" call, make the "no handler" path in
loggers emit messages *as if* basicConfig() has been called (without
actually calling it)
2. Remove the implicit calls to basicConfig() from the module level
convenience function

How *feasible* that idea is to implement, I don't know.

Cheers,
Nick.
-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia