Logging with Logger hierarchies

[Robert]

Hi all

I have been trying to set up a framework with logging implemented using
the built in Python logging module. For better or worse, I have decided
to base the logger names on the module names. This means that I am
using multiple layers of name, eg logging.getLogg er("a.b.c"). I am also
using logging.config to load a file configuration but have been
experiencing some unexpected behaviour.

If for instance I have something resembling the following code:

import logging
import logging.config
logging.config. fileConfig("log ging.conf")
logger = logging.getLogg er("a.b.c")
logger.debug("D ebug message")

and the file logging.conf describes only the root logger configuration
and specifies level=DEBUG. I get an message saying no handler found for
logger "a.b.c". What I would have expected was that my logger would
have inherited its handlers from root, ie through the parents a.b, up
to a and finally up to root.

I delved in the code and found that when my logger "a.b.c" is created,
it doesn't create Loggers for "a.b" or "a" but rather instances of a
PlaceHolder class. If I actually call logging.getLogg er("a.b") and
logging.getLogg er("a") then the PlaceHolders get converted to Loggers
and the hierarchy suddenly works.

My feeling is that either the PlaceHolder objects should be modified to
make them work properly in the hierarchy, or probably more simply, they
should just be replaced by Loggers immediately when the hierarchy is
first created. In that case, I believe that my expected behaviour would
"just work". Now I am beginning to wonder if I have missed something,
ie is there some reason why this is not a good idea and hasn't been
done? Otherwise, what do people generally think? Is it as simple as I
haven't set something up right, or do I have to declare the
intermediate loggers, or does having multiple layers just suck!!!

Useful comment welcome!
Robert

[Vinay Sajip]

Re: Logging with Logger hierarchies

I delved in the code and found that when my logger "a.b.c" is created,

it doesn't create Loggers for "a.b" or "a" but rather instances of a
PlaceHolder class. If I actually call logging.getLogg er("a.b") and
logging.getLogg er("a") then the PlaceHolders get converted to Loggers
and the hierarchy suddenly works.
>
My feeling is that either the PlaceHolder objects should be modified to
make them work properly in the hierarchy, or probably more simply, they
should just be replaced by Loggers immediately when the hierarchy is
first created. In that case, I believe that my expected behaviour would
"just work". Now I am beginning to wonder if I have missed something,
ie is there some reason why this is not a good idea and hasn't been
done? Otherwise, what do people generally think? Is it as simple as I
haven't set something up right, or do I have to declare the
intermediate loggers, or does having multiple layers just suck!!!

There is nothing wrong with the way you are naming your loggers - and
there is nothing wrong with the way PlaceHolders work, either. They do
just "work", AFAIK. If there were something wrong with your config
file, no handler might get configured on the root logger, which would
lead to the observed behaviour when you log to "a.b.c".

With the simple script

import logging

logging.basicCo nfig(level=logg ing.DEBUG,
format="%(name) s: %(levelname)-5s: %(message)s")
logging.getLogg er("a.b.c").deb ug("Hello, world!")

I get the output

a.b.c: DEBUG: Hello, world!

which is as expected.

Regards,

Vinay Sajip

[Robert]

Re: Logging with Logger hierarchies

Hi again

I have seen my error! I was mistakenly occasionally creating the logger
using

logger = logging.Logger( "a.b.c")

instead of

logger = logging.getLogg er("a.b.c")

Doh. I miss my private constructors to save me from such embarrasment
;^)

Cheers
Robert