At 10:13 AM 6/6/2006 -0400, Jim Jewett wrote: >On 6/5/06, Phillip J. Eby <[EMAIL PROTECTED]> 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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
