Support bg+fg for log_color/log_message_color

[the01]

Enhancement

• Added option for log_message_color, which (like log_color) is
  intended to provide debug level specific coloring for the message (set via log_message_colors in init)
• Added support for simultaneous fg and bg color settings in
  log_color/log_message_color by appending another code after a single whitspace
  example:

formatter = ColoredFormatter(
        "%(log_color)s%(levelname)-8s%(reset)s %(blue)s%(message)s",
        datefmt=None,
        reset=True,
        log_colors={
            'DEBUG':    'cyan',
            'INFO':     'green',
            'WARNING':  'yellow',
            'ERROR':    'red',
            'CRITICAL': 'white bg_red',
        }
)

[borntyping]

Initial thoughts - I'm not very clear on what log_message_color is for - are you able to provide an example?

[borntyping]

I like the idea of supporting fg and bg colors at the same time - though if that gets added I'd prefer it to work anywhere a color could be specified. I've got some ideas for that, but they haven't been needed until now - this would include parsing any keys provided by the record (and would potentially support #7). In short, I'll probably change the way that's implemented before releasing a new stable version.

[the01]

@initial thoughts: Basically whenever I log something, that line has to parts:

• the "header" (time, logger, log level,..)
• and the message (the actual string you want to log)
  the above format string would look like this actually
  '''python
  "%(log_color)s%(levelname)-8s%(reset)s %(log_message_color)s%(message)s"
  '''
  it is basically a second log_color to include a log level aware color mapping. A generic approach for n log level aware mappings is propably cleaner though.

I am not exactly sure what you are getting at in the other comment. The problem here was that you explicitly parsed the color_name. Anywhere else you would just do a %(bg_blue)s%(white)s, or am I missing something?

[borntyping]

Right, okay :)

A generic approach for n log level aware mappings is propably cleaner though.

The approach I'm considering is this, letting a user have any number of alternate mappings.

ColoredFormatter(
    "%(log_color)s%(levelname)-8s%(reset)s %(log_color_message)s%(message)s",
    alternate_log_colors={
        'message': {
            'DEBUG': 'blue',
            ...
        }
    }
}

Anywhere else you would just do a %(bg_blue)s%(white)s, or am I missing something?

Correct - though what I'd like to do is allow any color spec to use multiple codes (which could include other codes like bold or underline). So you could have %(white,bg_blue)s in a format, or 'DEBUG': 'fg_white,bg_blue' in a log_colors parameter.

I'm happy to merge this and adapt it - my primary concern is getting the API of any new features right 😄

[the01]

The approach I'm considering is this, letting a user have any number of alternate mappings.

Yes, I already had similar code in mind. I was actually about to start a new project and thought 'A little coloring would be nice for the output'. That is when I came across your project. I loved the debug level specific coloring, but being a bit color blind, I needed the bg/fg combination to see a difference on the first glance.
So I had already written some test call with the 2 nested dicts, but I couldn't figure out a nice clean way to implement this. After 20 minutes or so I gave up, did only the things I needed and (finally) started the other project.
It is funny how easily you can get sidetracked sometimes 😄

Correct - though what I'd like to do is allow any color spec to use multiple codes (which could include other codes like bold or underline). So you could have %(white,bg_blue)s in a format, or 'DEBUG': 'fg_white,bg_blue' in a log_colors parameter.

Basically you want the format string to be cleaner (%(white,bg_blue)s is aquivalent to %(white)s&%(bg_blue)s).
I am not very familiar with logging formatters, but isn't the format string only set in the constructor? Which means the easiest solution, albeit not a very beautiful one, would be to parse the string in init() and split the compact form (%(white,bg_blue)s) into the inelegant one (%(white)s%(bg_blue)s).

I'm happy to merge this and adapt it - my primary concern is getting the API of any new features right 😄

I absolutely agree with you there..but it is sometimes just so hard to predict where a project might go in the future and what will be needed.

[borntyping]

Okay, I'll start work on adapting this once I'm at my dev machine 😄

I am not very familiar with logging formatters, but isn't the format string only set in the constructor? Which means the easiest solution, albeit not a very beautiful one, would be to parse the string in init() and split the compact form (%(white,bg_blue)s) into the inelegant one (%(white)s%(bg_blue)s).

Basically, records are formatted with something like format_string.format(**record.__dict__)[1][2]. I'm hoping to wrap the record with another object that will parse any missing attributes that the format string uses as escape sequences, instead of adding a set of escape sequences to the record (which is something I've been meaning to do for a while).

[borntyping]

This has been merged into the develop branch. An explaination of the new format is here: Using secondary log colors. Any comments before this is released?

[the01]

looks good from a quick glance! Maybe an example for using multiple codes with the ',' would be nice?

[borntyping]

Thanks, missed that :) I'll add an example tomorrow!