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

[Phillip J. Eby]

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.