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

Phillip J. Eby pje at telecommunity.com
Tue Jun 6 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.

More information about the Python-Dev mailing list