Error reporting by logging.config.fileConfig()

[mike]

BPO	6399
Nosy	@vsajip, @bitdancer

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2009-07-08.16:47:54.950>
created_at = <Date 2009-07-02.09:50:30.229>
labels = ['extension-modules', 'type-feature', 'invalid']
title = 'Error reporting by logging.config.fileConfig()'
updated_at = <Date 2009-07-08.23:10:28.332>
user = 'https://bugs.python.org/mike'

bugs.python.org fields:

activity = <Date 2009-07-08.23:10:28.332>
actor = 'vinay.sajip'
assignee = 'none'
closed = True
closed_date = <Date 2009-07-08.16:47:54.950>
closer = 'mike'
components = ['Extension Modules']
creation = <Date 2009-07-02.09:50:30.229>
creator = 'mike'
dependencies = []
files = []
hgrepos = []
issue_num = 6399
keywords = []
message_count = 8.0
messages = ['90007', '90036', '90044', '90068', '90227', '90235', '90273', '90293']
nosy_count = 3.0
nosy_names = ['vinay.sajip', 'r.david.murray', 'mike']
pr_nums = []
priority = 'low'
resolution = 'not a bug'
stage = None
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue6399'
versions = ['Python 2.6']

[mike]

Hi,
I had a logging.conf file with the following logger def in it:

[logger_Builder]
level=DEBUG
handlers=consoleStderr
qualname=Builder
propogate=0

And I couldn't understand why all my log messages were coming out twice.
It took me four hours :-\ to realise I had misspelt "propagate".

Wouldn't it be better if spurious names raised parsing exceptions?

Thanks,
Mike.

P.S. Another thing that might have helped me track this down a little
quicker is if I could have printed the name of the logger that was the
source of some output. %(name)s gives the logger that *received* the log
message. If there was another format variable for the logger that was
the source of a log message I would have seen one message from Builder
and one message from root and it would have been more obvious what was
going on.

[bitdancer]

Ignoring unknown options in the configuration file is analogous to
ignoring unknown tags in html: it makes it easier to use the same config
file with multiple versions of the logger, with older versions ignoring
the options they don't understand. This is a tradeoff, and I suppose it
could be argued that the tradeoff is being made in the wrong direction
here. I don't use configuration files for logging myself, so I'm not a
good person to render an opinion on that.

But IMO this is not a bug; changing the behavior would be a feature request.

[mike]

Fair point. Agree that this is a feature request. Perhaps something like:

logging.config.fileConfig(path, strict=False)

[vsajip]

I'm not sure that this is a valid feature request. As R. David Murray
has said, it's sort of an unwritten rule of ConfigParser-based
applications that they look for specific entries, but don't care what
else is there in the file - sort of in line with Postel's Law.

The appearance of multiple messages pretty much points to multiple
handlers handling the message; knowing the way the hierarchy works,
propagation should have been one of the first things to check (as I
assume you had added handlers both at and above [logger_Builder]. I know
hindsight is wonderful, and I'm sorry it took you 4 hours to find the
problem; but I'm not convinced by this that I need to put more error
checking into the fileConfig code.

[mike]

Sorry, I only started learning Python a couple of weeks ago. Didn't
know that there was a ConfigParser module. So this would really be a
feature request of ConfigParser?

Interesting you should mention Postel's Law. Being liberal about what
you accept from others doesn't mean ignoring non-conformance. Jon
Postel was clear that although you endeavour to continue when
encountering non-conformance you should always report it, lest
non-conformance propogates (sic).

I can think of two ways ConfigParser could report these problems.
Either you give it a callback function it can call as it encounters
problems, or, after you have parsed a file you can call another function
that gives a list of any problems encountered.

If ConfigParser had this functionality it would then be straightforward
for the logging.config.fileConfig module to send these warnings to the
root logger.

[vsajip]

Well, there are other systems around (e.g. ConfigObj) which will allow
you to validate against a schema, but it's not part of the core so
logging can't rely on it.

I'm not sure how much interest there'd be in adding this kind of
validation to ConfigParser, but you could always try working up a patch
and assigning it to whoever maintains ConfigParser, or contacting that
person beforehand to see if it's worth it, or posting on c.lpy with the
same objective.

[mike]

Hi Vinay,
I will bow to your greater expertise on this and will let this go.
It looks like it will be far more easier and robust just to invent my
own logging config file format and read it myself.
Thanks for your help.
Mike.

[vsajip]

Mike,

That's just fine. Sorry if I appear unhelpful, but in the open source
world we mostly scratch our own itches. I believe I have a reasonable
record on accepting patches from the community (though I don't of course
accept everything), and I unfortunately don't have much time to spend on
this because of other, more pressing itches :-(

Best of luck with it.