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." I certainly agree that the PEP as written should not be treated as fully pronounced. I do think the discussion was stalled until we have a specific implementation to discuss. Google is generously funding one, and Jackilyn is providing it. I'm checking in here because when changes are needed, I would prefer that she know as soon as possible. Jackilyn has made it quite clear that she is willing to change her direction if we ask her to, she just needs to know what the goals are. > The original discussion that occurred prior to PEP 337's creation discussed > only modules that *already* do some kind of logging. There was no > discussion of changing *all* debugging output to use the logging module, > nor of adding logging to modules that do not even have any debugging output > (e.g. pkgutil). You may be reading too much ambition into the proposal. 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. The difference is that if a sysadmin does want to track problems, the change can now be made in one single place. Today, turning on that instrumentation would require separate changes to every relevant module, and requires you to already know what/where they are. I did ask whether extra debugging/instrumentation information should be added where it isn't already present. I personally think the answer is yes, but it sounds like the consensus answer is "not now" -- so she generally won't. -jJ _______________________________________________ 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
