Logging oddity: handlers mandatory in every single logger?

Masklinn masklinn at masklinn.net
Wed Feb 3 03:50:26 EST 2010


On 2 Feb 2010, at 17:52 , Jean-Michel Pichavant wrote:
> 
> Masklinn wrote:
>> Jean-Michel Pichavant wrote:
>>  
>>> To add a custom level, I would proceed that way:
>>> 
>>> logging.ALERT = 45
>>> logging.addLevelName(logging.ALERT, 'ALERT !!')
>>> logging.getLogger().log(logging.ALERT, 'test')
>>> 
>>> Passing a string to the log method as you did is incorrect.
>>>    
>> 
>> I know it's currently incorrect. My point was more along the line that there was *no reason* for it to be incorrect. logging already contains all the tools for log('PANTS_ON_FIRE') to be allowed
>>  
> The reason is that log takes an *int* as first argument that defines the logging level. You gave a string. So There is definitely a reason for it to be incorrect.
That's not a reason, that's just what currently happens. I know it doesn't work, and I know why, I went and checked the code. But there's no fundamental reason why you couldn't use a level *name* instead of a level code. And indeed, in most parts of logging you can (including but not limited to the configuration of handlers and loggers)

>>  
>>> Regarding your first point, I guess it's anti pattern. One way to do it:
>>> 1/ Configure the root logger with the lowest value 0, so the root logger does not filter any level.
>>> 2/ Configure each of your logger with the correct level
>>> 
>>> That way you can configure your '0' logger as you (badly :o)) named it with one level, and configure a potential '1' logger with another level. Don't bother with propagation. That way you won't need to duplicate your handlers on every logger.
>>>    
>> 
>> re logger 0, no need for complex name for a test case (and it allowed me to create easy-to-remember 0.1 and 0.1.2 if needed)
>> 
>> Re your answer, from what I understand you want the root logger to NOTSET and then each child logger with its correct level? But that's not a solution, each and every level will *still* require a handler explicitly configured on it. That's in fact very much my issue: logging refuses that a logger be handler-less in a config file, it's mandatory to configure a handler any time a logger is configured.
>>  
> the field handlers must be defined even if empty.
Ah, interesting, I didn't think it could be defined as empty.

Which makes the requirement to have an empty ``handler`` completely nonsensical, doesn't it?




More information about the Python-list mailing list