[Python-Dev] Stdlib Logging questions (PEP 337 SoC)
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
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
>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