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

[Phillip J. Eby]

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.