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

Phillip J. Eby pje at telecommunity.com
Mon Jun 5 05:42:04 CEST 2006

At 09:27 PM 6/4/2006 -0400, Jim Jewett wrote:

Jackilyn is adding logging to several stdlib modules for the Google Summer of Code (PEP 337), and asked me to review her first few changes.

That PEP doesn't appear to have been approved, and I don't recall any discussion on Python-Dev. I also couldn't find any in the archives, except for some brief discussion regarding a small fraction of the huge list of modules in PEP 337.

I personally don't see the value in adding this to anything but modules that already do some kind of logging. And even some of the modules listed in the PEP that do some kind of output, I don't really see what the use case for using the logging module is. (Why does timeit need a logger, for example?)

There were a few comments that I felt I should double-check with Python-dev first, in case my own intuition is wrong.

For reference, she is adding the following prologue to several modules: import logging log = logging.getLogger('py.NAME') where NAME is the module name

If this has to be added to the modules that don't currently do any logging, can we please delay the import until it's actually needed? i.e., until after some logging option is enabled? I don't really like the logging module myself and would rather it were not imported as a side effect of merely using shlex or pkgutil!

(5) Should she clean up other issues when touching a module?

In general, stdlib code isn't updated just for style reasons,

Which is a good enough reason, IMO, to vote -1 on the PEP if it's not pared back to reflect only modules with a valid use case for logging.

I think it would be a good idea to revisit the module list. I can see a reasonable case for the BaseHTTP stuff and asyncore needing a logging framework, if you plan to make them part of some larger framework -- the configurability would be a plus, even if I personally don't like the way the logging module does configuration. But most of the other modules, I just don't see why something more complex than prints are desirable. As of Python 2.5, if you want stdout or stderr temporarily redirected, it's easy enough to wrap your calls in a with: block.

More information about the Python-Dev mailing list