Add support for per-loglevel formatting#32
Conversation
|
This is pretty cool, though is quite far from the modules original scope. I think this behaviour might be better placed in a subclass of the
Not worried about the naming of
I like this idea of reusing |
|
Thanks for the feedback! I hope you don't mean it is too far from your original idea of colorlog to get merged.
Actually, this is how I had originally implemented it, but I decided to merge it into
So should I just remove the whole
OK, I'll rewrite it to reuse |
If fmt is a dict, it is now used as a mapping of log levels to different formatters. default_level_formats is no longer used internally.
|
Yep - happy to use this in colorlog, I'd just greatly prefer to put it in a subclass.
I think |
|
I was a bit confused about when I have to call the superclass functions at first, but I've just managed to write my new code exclusively into a subclass without duplicating any code from ColoredFormatter. Do you have a suggestion how to name this new class? I chose "ColoredLevelFormatter" for now, but that might sound a bit awkward. |
|
Maybe just |
|
|
|
Thanks a lot for merging this! |
|
Thanks for all the work you've put in :) |
Add support for per-loglevel formatting
This makes it possible to specify a formatter dictionary that enables colorlog to format messages differently based on their log level.
Use case:
logger.info(), you are rarely interested in the module and line number where the message comes from.This is why I added the
level_fmtsargument to ColoredFormatter.I tested the new code with Python 2.7 and Python 3.5.
Possible issues:
default_level_formatshas nothing to do with colorlog's normaldefault_formats. Could this be confusing?fmtargument instead of introducing the newlevel_fmts. We would need to check iffmtis a dict or a string inColoredFormatter.__init__()and could use it differently depending on the type. I don't know if that would be better. What is your opinion?