[Python-Dev] Stdlib Logging questions (PEP 337 SoC)

Tue Jun 6 18:18:27 CEST 2006

At 10:13 AM 6/6/2006 -0400, Jim Jewett wrote:
>On 6/5/06, Phillip J. Eby <pje at telecommunity.com> wrote:
>>>I notice you've completely avoided the question of whether this should be
>>being done at all.
>>>As far as I can tell, this PEP hasn't actually been discussed. Please
>>don't waste time changing modules for which there is no consensus that this
>>*should* be done.
>>Under a specific PEP number, no. The concept of adding logging to the
>stdlib, yes, periodically. The typical outcome is that some people
>say "why bother, besides it would slow things down" and others say
>"yes, please."

All the conversations I was able to find were limited to the topic of 
changing modules that *do logging*, not modules that have optional 
debugging output, nor adding debugging output to modules that do not have 
it now. I'm +0 at best on changing modules that do logging now (not debug 
output or warnings, *logging*). -1 on everything else.
>You may be reading too much ambition into the proposal.

Huh? The packages are all listed right there in the PEP.
>For pkgutil in particular, the change is that instead of writing to
>stderr (which can scroll off and get lost), it will write to the
>errorlog. In a truly default setup, that still ends up writing to
>stderr.

If anything, that pkgutil code should be replaced with a call to 
warnings.warn() instead.
>The difference is that if a sysadmin does want to track problems, the
>change can now be made in one single place.

Um, what? You mean, one place per Python application instance, I 
presume. Assuming that the application allows you to configure the logging 
system, and doesn't come preconfigured to do something else.
> Today, turning on that
>instrumentation would require separate changes to every relevant
>module, and requires you to already know what/where they are.

And thus ensures that it won't be turned on by accident.