By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,446 Members | 1,566 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,446 IT Pros & Developers. It's quick & easy.

Logging with Logger hierarchies

P: n/a
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.getLogger("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("logging.conf")
logger = logging.getLogger("a.b.c")
logger.debug("Debug 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.getLogger("a.b") and
logging.getLogger("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

Oct 20 '06 #1
Share this Question
Share on Google+
2 Replies


P: n/a
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.getLogger("a.b") and
logging.getLogger("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.basicConfig(level=logging.DEBUG,
format="%(name)s: %(levelname)-5s: %(message)s")
logging.getLogger("a.b.c").debug("Hello, world!")

I get the output

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

which is as expected.

Regards,

Vinay Sajip

Oct 20 '06 #2

P: n/a
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.getLogger("a.b.c")

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

Cheers
Robert

Oct 20 '06 #3

This discussion thread is closed

Replies have been disabled for this discussion.