Logging oddity: handlers mandatory in every single logger?

Masklinn masklinn at masklinn.net
Wed Feb 3 06:36:53 EST 2010


On 3 Feb 2010, at 11:50 , Jean-Michel Pichavant wrote:
> 
> 
>>> 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)
>> 
> You don't neeed to check the code for that ! It is written in the documentation. The logging module designer choose to ask for a level, not a level name, possibly because 2 different levels can have the same name.
> 
Nope, 2 different levels cannot have the same name: levels are currently stored in a dict of string:level and level:string, so you can't have 2 names for the same level, and you can't have 2 levels with the same name either.

>>> 
>>> 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?
> 'completeley nonsensical' is overstating.  It make sense to state that your handler list is empty, when it is empty.
Programmatically, that's implied in the fact that you aren't specifying it. Why wouldn't it be in the config file? Why the asymetry here?




More information about the Python-list mailing list