R
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.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
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