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

Jim Jewett jimjjewett at gmail.com
Mon Jun 5 03:27:09 CEST 2006

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

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

(1)  Should we ask Vinay Sajip to add a convenience function (for
getting the stdlib logger) to the logging module itself?

It seems like it might be overkill, amd it wouldn't save even a single line.

On the other hand, I wonder if we will eventually end up wanting a
common choke point for hooks.  PEP 337 did not recommend any such
function, and recommended setting the handlers and level for py.* as
sufficient control.

So I'm inclined to say "no changes to the logging package itself".

(2)  Should NAME be module.__name__?

Note that this means the log messages would be different when the
module is run as a script (and the name is therefore __main__).

I'm not thrilled with repeating the module name as a string, but I
think that may be the lesser of evils.

(3)  Should she put out a message when a (now logged) module is
loaded?  If so, at what level?

I'm leaning towards

    _log.debug("Stdlib NAME loaded as ", __name__)

(4)  Should she add (other) debugging information that is not already present?

I think that "if __debug__: print ..." or "if debuglevel>0:
sys.stdout.write..." should be changed, and things like set_debuglevel
should be translated to calls to change the level of the appropriate

What about print lines that are currently commented out?  Should these
be displayed at debug level?  (I think so.)

What about useful information that isn't currently displayed?  For
instance, the asyncore module is careful to reuse a global mapping if
it already exists (presumably from a reload), but that seems rare
enough that it should be worth at least an info message.

What about normal config info, such as the typical case of creating an
empty mapping?  In Java, I would expect a CONFIG message either way.
In python, that seems like too much of a change, but ... at debug
level ... maybe not doing it is just a bad habit.

Unless convinced otherwise, I'll ask her to use debug for commented
out lines that were still important enough to leave in the code, info
message for unexpected choices, and not to bother with logging "yup,
did the normal thing"

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

In general, stdlib code isn't updated just for style reasons, unless
there is a deprecation -- but in these cases, the module is already
changing slightly.

My inclination would be that she doesn't have to fix everything, but
should generally do so when either it is "easy" or the old code is
arguably a bug (such as bare excepts).  (And "easy" might change as
the summer wears on.)


More information about the Python-Dev mailing list