I found that the configuration system of the new logging package of Python
2.3 has some
unintuitive idiosyncracies that are worth mentioning because they can cost
you quite some
development time and are not documented elsewhere.
I used the logging configuration file shown below. My aim was to log only
the INFO messages,
but log DEBUG messages for one particular module (called webTestLogin.py ).
Here's what I found out:
- if your init logging in your module with the line
log = logging.getLogg er()
then the logging module will determine the module where the call
originated and in your log files
you'll find lines like
2004-01-26 11:21:15,890 [INFO] creating ticket for this session
[in webtestlogin]
where webTestLogin mysteriously lost its capitalization. Now, this does
*not* mean that
webtestlogin will also be the 'qualname', i.e. the name of a channel
that you can use
to log messages from this module to a different place or in a different
manner; for that
to work, you'll need the following line of code:
log = logging.getLogg er('webtestlogi n')
(making 'webtestlogin' a channel, or some sort of logical logging unit
that allow its calls to be handled
differently from the other log calls in your program).
The documentation says qualname is the 'fully qualified name', but
doesn't contend on what
that is; I tried the complete package name, that didn't work
('com.cellzome. pandora.webTest Login').
- capitalization *is* very important; if you use lowercase in the code,
you'll need lowercase
in the logging config file as well (see the qualname line below)
- 'propagate' forwards log messages to other loggers, so you may e.g. log
the same line to
two different places - so far so good. But: If you set propagate to 1 in
the [logger_webtestl ogin]
shown below, the root logger will log DEBUG messages too, even though it
was told to log
only INFO - just because the message has been forwarded (?!?)
Generally I think that propagation follows the order of the loggers, but
I still don't get the
complete picture.
- the config file scanner/parser is not very robust; if you use spaces in
a list for aesthetic reasons
(e.g. keys=root, webtestlogin) the key list will be ('root', '
webtestlogin'). This can produce
quite esoteric errors :-)
Maybe I didn't get the point/purpose of the framework on some of those
issues, but
then again it might be worth to extend the existing documentation a bit.
Cheers,
Robert F Schmitt, Cellzome AG
Meyerhofstr. 1, D-69117 Heidelberg, Germany
Tel + 49 6221 137 57 405, Fax + 49 6221 137 57 202
------------------------------------------------------------------------------------
The vast majority of our imports come from outside the country."
- George W. Bush
"If we don't succeed, we run the risk of failure."
- George W. Bush
///////////////////////////////////////////////////////////////////
/////////////// config file ///////////////
///////////////////////////////////////////////////////////////////
############### ############### ############### ##############
# general references
[loggers]
keys=root,webte stlogin
[handlers]
keys=drogenHand ler,stdoutHandl er
[formatters]
keys=taschenFor mat,textOnlyFor mat
############### ############### ############### ##############
# loggers
[logger_webtestl ogin]
level=DEBUG
handlers=drogen Handler,stdoutH andler
propagate=0
qualname=webtes tlogin
[logger_root]
level=INFO
handlers=drogen Handler,stdoutH andler
propagate=1
############### ############### ############### ##############
# handlers
[handler_drogenH andler]
class=FileHandl er
level=NOTSET
formatter=tasch enFormat
args=('pandora. log', 'w')
[handler_stdoutH andler]
class=StreamHan dler
level=INFO
formatter=textO nlyFormat
args=(sys.stdou t,)
############### ############### ############### ##############
# formatters
[formatter_tasch enFormat]
format=%(asctim e)s [%(levelname)s] %(message)s [in %(module)s]
[formatter_textO nlyFormat]
format=%(leveln ame)s %(message)s
2.3 has some
unintuitive idiosyncracies that are worth mentioning because they can cost
you quite some
development time and are not documented elsewhere.
I used the logging configuration file shown below. My aim was to log only
the INFO messages,
but log DEBUG messages for one particular module (called webTestLogin.py ).
Here's what I found out:
- if your init logging in your module with the line
log = logging.getLogg er()
then the logging module will determine the module where the call
originated and in your log files
you'll find lines like
2004-01-26 11:21:15,890 [INFO] creating ticket for this session
[in webtestlogin]
where webTestLogin mysteriously lost its capitalization. Now, this does
*not* mean that
webtestlogin will also be the 'qualname', i.e. the name of a channel
that you can use
to log messages from this module to a different place or in a different
manner; for that
to work, you'll need the following line of code:
log = logging.getLogg er('webtestlogi n')
(making 'webtestlogin' a channel, or some sort of logical logging unit
that allow its calls to be handled
differently from the other log calls in your program).
The documentation says qualname is the 'fully qualified name', but
doesn't contend on what
that is; I tried the complete package name, that didn't work
('com.cellzome. pandora.webTest Login').
- capitalization *is* very important; if you use lowercase in the code,
you'll need lowercase
in the logging config file as well (see the qualname line below)
- 'propagate' forwards log messages to other loggers, so you may e.g. log
the same line to
two different places - so far so good. But: If you set propagate to 1 in
the [logger_webtestl ogin]
shown below, the root logger will log DEBUG messages too, even though it
was told to log
only INFO - just because the message has been forwarded (?!?)
Generally I think that propagation follows the order of the loggers, but
I still don't get the
complete picture.
- the config file scanner/parser is not very robust; if you use spaces in
a list for aesthetic reasons
(e.g. keys=root, webtestlogin) the key list will be ('root', '
webtestlogin'). This can produce
quite esoteric errors :-)
Maybe I didn't get the point/purpose of the framework on some of those
issues, but
then again it might be worth to extend the existing documentation a bit.
Cheers,
Robert F Schmitt, Cellzome AG
Meyerhofstr. 1, D-69117 Heidelberg, Germany
Tel + 49 6221 137 57 405, Fax + 49 6221 137 57 202
------------------------------------------------------------------------------------
The vast majority of our imports come from outside the country."
- George W. Bush
"If we don't succeed, we run the risk of failure."
- George W. Bush
///////////////////////////////////////////////////////////////////
/////////////// config file ///////////////
///////////////////////////////////////////////////////////////////
############### ############### ############### ##############
# general references
[loggers]
keys=root,webte stlogin
[handlers]
keys=drogenHand ler,stdoutHandl er
[formatters]
keys=taschenFor mat,textOnlyFor mat
############### ############### ############### ##############
# loggers
[logger_webtestl ogin]
level=DEBUG
handlers=drogen Handler,stdoutH andler
propagate=0
qualname=webtes tlogin
[logger_root]
level=INFO
handlers=drogen Handler,stdoutH andler
propagate=1
############### ############### ############### ##############
# handlers
[handler_drogenH andler]
class=FileHandl er
level=NOTSET
formatter=tasch enFormat
args=('pandora. log', 'w')
[handler_stdoutH andler]
class=StreamHan dler
level=INFO
formatter=textO nlyFormat
args=(sys.stdou t,)
############### ############### ############### ##############
# formatters
[formatter_tasch enFormat]
format=%(asctim e)s [%(levelname)s] %(message)s [in %(module)s]
[formatter_textO nlyFormat]
format=%(leveln ame)s %(message)s