[Python-Dev] Stdlib Logging questions (PEP 337 SoC)
Phillip J. Eby
pje at telecommunity.com
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
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
If anything, that pkgutil code should be replaced with a call to
>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.
More information about the Python-Dev