This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pakal
Recipients pakal
Date 2010-04-06.17:21:04
SpamBayes Score 0.00059355603
Marked as misclassified No
Message-id <1270574466.45.0.74894426001.issue8327@psf.upfronthosting.co.za>
In-reply-to
Content
Hello

Crawling into the logging module, I've just discovered its behaviour was actually far from the one I expected, in a consequent gap that the documentation had left.

I thought that depending on the "propagate" parameter of each logger, a message would always try to propagate up the logger hierarchy, and that if that message matched the level of a logger (as well as the global disable() level), then this message would be tested against each handler of that logger.

But it's not at all the way it is : actually, only the level of the "entrance" logger is checked ; if the message is blocked by it, it's the end, parent loggers will never hear about it (even thoiugh they might have a lower level set). On the contrary, if that entrance logger accepts the message, then ALL handlers from the hierarchy are snet the message, without caring about the own level of their related logger.

That's really not the behaviour I would have expected, considering the global_disable > logger_level > handler_level precedence that the doc implicitly showed. Are there rationales behind this that I'm lacking ?

So I'd advocate either (if possible) a patching of the logging system, to reflect that semantic ; or the adding of comprehensive paragraphs to teh doc, to explain what the exact relationship between levels and propagation attribuets are.
Just tell me if a patch is conceivable B-)
History
Date User Action Args
2010-04-06 17:21:06pakalsetrecipients: + pakal
2010-04-06 17:21:06pakalsetmessageid: <1270574466.45.0.74894426001.issue8327@psf.upfronthosting.co.za>
2010-04-06 17:21:04pakallinkissue8327 messages
2010-04-06 17:21:04pakalcreate