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?
--
http://mail.python.org/mailman/listinfo/python-list
