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',
        }
)

Without colorama installed, the provided ColoredFormatter will always use colors, even when redirected to a file (ie. $ ./command.py 2> error_out.txt)

When colorama is installed, colorama detects a non-tty, and strips the colors.

Since colorlog provides a TTYColoredFormater that will strip colors for a non-tty, the above behavior seems not only inconsistent, but unintended. (ie. the user chooses stripping for non-tty by choosing TTYColoredFormater instead of ColoredFormatter, not by having or not having colorama installed.)

I therefore suggest that the colorama init should be called as: colorama.init(strip=False) or minimally some other option should be available to colorlog users to 'force' colors or prevent stripping.

I like my logs to have color even when redirected to files. Using 'less -R' let's you still benefit from the colors when reviewing the output.

This makes it possible to specify a formatter dictionary that enables colorlog to format messages differently based on their log level.

Use case:

• If you want to log informational output using logger.info(), you are rarely interested in the module and line number where the message comes from.
• On the other hand, it can be useful to prefix warnings, errors and criticals with 'WARNING: ' etc. and add line number and module at the end, for example.

This is why I added the level_fmts argument to ColoredFormatter.

I tested the new code with Python 2.7 and Python 3.5.

Possible issues:

• default_level_formats has nothing to do with colorlog's normal default_formats. Could this be confusing?
• We could reuse the fmt argument instead of introducing the new level_fmts. We would need to check if fmt is a dict or a string in ColoredFormatter.__init__() and could use it differently depending on the type. I don't know if that would be better. What is your opinion?

Awesome package, very nicely done!

I was wondering why the basicConfig only has the fmt and datefmt option instead of all the ColoredFormatter options since you directly use this class?

I have added them like this and it seems to work fine. Perhaps I'm missing something in how to use the package but this way I can simply use the basicConfig without creating any new handlers etc. and still choose my own colors :+1:

def basicConfig(**kwargs):
    """Call ``logging.basicConfig`` and override the formatter it creates."""
    logging.basicConfig(**kwargs)
    logging._acquireLock()
    try:
        stream = logging.root.handlers[0]
        stream.setFormatter(
            ColoredFormatter(
                fmt=kwargs.get('format', BASIC_FORMAT),
                datefmt=kwargs.get('datefmt', None),
                style=kwargs.get('style', '%'),
                log_colors=kwargs.get('log_colors', None),
                reset=kwargs.get('reset', True),
                secondary_log_colors=kwargs.get('secondary_log_colors', None)))
    finally:
        logging._releaseLock()

There should be a switch to deactivate the color output. Most of the time for debug purpose.

I use my code on Linux (bash) and Windwos10 (Thonny Pythton GUI). The latter is not able to handle the color codes and output all the escape characters. This is ugly.

I just want to deactivate the color-escape sequences but not the other settings (e.g. format).

Hi,

If already supported, could you please detail how to set a custom logging level with an associated color and formatting? Otherwise that would be a nice addition!

Thanks

This intends to solve a rare problem I had encountered. I use both colorlog and multiprocessing-logging. I noticed that in the subprocesses, if I call logger.exception, I do get the message but not the traceback. I tracked down the issue to this line, where multiprocessing-logging calls format(record), expecting the formatter to set record.exc_text. Since the ColoredFormatter wraps the record before calling the base class, the original record doesn't get it's exc_text set, and I lose my traceback. I think that this issue is much easier to fix in colorlog. I removed the ColoredRecord and instead just set the escape code properties to the original record.

Asking here primarily to see if you know an obvious reason why this is happening:

I'm sometimes getting a double logging output in my log:

1-19 14:26:36 DEBUG    First dates from partial predictions: {'transfer_rates': datetime.date(2020, 10, 5), 'orders_day': datetime.date(2020, 10, 5), 'units_order': datetime.date(2020, 10, 5)}
11-19 14:26:36 DEBUG    First date of joint prediction: 2020-10-05
11-19 14:26:36 DEBUG    Days predicted in partial predictions fron joint first date: {'transfer_rates': 42, 'orders_day': 42, 'units_order': 42}
11-19 14:26:36 DEBUG    Last date of joint prediction: 2020-11-15
11-19 14:26:38 DEBUG    Using expected new [[ 850. 1200. 1200. 1200. 3000. 3000. 3000.]]
11-19 14:26:38 DEBUG    Using expected winback [[2400. 2600. 2600. 2500. 3000. 3000. 3200.]]
11-19 14:26:38 DEBUG    Added noise to expected new and winback
11-19 14:26:38 DEBUG    Normalize ranges and draws on prediction for transfer_rates
DEBUG:main:Normalize ranges and draws on prediction for transfer_rates
11-19 14:26:38 DEBUG    Normalize ranges and draws on prediction for orders_day
DEBUG:main:Normalize ranges and draws on prediction for orders_day
11-19 14:26:38 DEBUG    Normalize ranges and draws on prediction for units_order
DEBUG:main:Normalize ranges and draws on prediction for units_order
11-19 14:26:38 INFO     Add adjustments
INFO:main:Add adjustments

The white lines containing :main: are the lines I do not expect. Once these lines start appearing, the double logs appear with every single logging statement.

We import a logger in our scripts that is defined as:

def make_logger(console=True):
    logger = logging.getLogger(name)
    logger.setLevel(level)

    if console:
        color_fmt = "%(log_color)s" if use_color and console else ""
        # some additional unrelated code here, removed for clarity
   
        # set logger stream variable so color only in interactive
        # terminals AND notebooks, preventing ANSI escape signatures
        # in grayscale log files
        stream = None if is_in_ipython_session() else sys.stderr

        formatter = colorlog.ColoredFormatter(
            fmt=color_fmt + log_format_for_console,
            datefmt=time_format_for_console,
            log_colors={
                "DEBUG": "blue",
                "INFO": "green",
                "WARNING": "yellow",
                "ERROR": "red",
                "CRITICAL": "bold_red,bg_white",
            },
            stream=stream,
        )
        if log_in_gmt:
            formatter.converter = time.gmtime

        handler = colorlog.StreamHandler()
        handler.setFormatter(formatter)

        logger.addHandler(handler)

I've use this as logger = make_logger(), and then e.g. logger.debug(...). I've noticed that I can trigger the double line behaviour if I accidentally call logging.debug instead of logger.debug, but that is not the case in the above.

Do you have any idea what's going on?

Traceback (most recent call last): File "D:/gitrep/DevOpsCI/DiasoftBuild/DiasoftBuild.py", line 36, in from LogInit import file_formatter File "D:\gitrep\DevOpsCI\DiasoftBuild\CommonLib\LogInit.py", line 98, in formatter = LevelFormatter( File "C:\Users\panov-ea\AppData\Roaming\Python\Python38\site-packages\colorlog\colorlog.py", line 160, in init super(LevelFormatter, self).init( File "C:\Users\panov-ea\AppData\Roaming\Python\Python38\site-packages\colorlog\colorlog.py", line 91, in init super(ColoredFormatter, self).init(fmt, datefmt, style) File "C:\Users\panov-ea\AppData\Local\Programs\Python\Python38-32\lib\logging_init_.py", line 576, in init self.style.validate() File "C:\Users\panov-ea\AppData\Local\Programs\Python\Python38-32\lib\logging_init.py", line 456, in validate for _, fieldname, spec, conversion in _str_formatter.parse(self._fmt): File "C:\Users\panov-ea\AppData\Local\Programs\Python\Python38-32\lib\string.py", line 261, in parse return _string.formatter_parser(format_string) TypeError: expected str, got dict

Python 3.6.0a4 64-bit on Windows

The following code produces an error with Python 3.6 but not Python 3.5:

import logging, colorlog

logger  = logging.getLogger()
handler = logging.StreamHandler()

handler.setFormatter(colorlog.ColoredFormatter(
    '{log_color}{levelname}:{reset} {message}', style = '{'))

logging.getLogger().addHandler(handler)

logger.error('TEST')

--- Logging error ---
Traceback (most recent call last):
  File "F:\PortableApps\Python3x\lib\logging\__init__.py", line 985, in emit
    msg = self.format(record)
  File "F:\PortableApps\Python3x\lib\logging\__init__.py", line 831, in format
    return fmt.format(record)
  File "F:\PortableApps\Python3x\lib\site-packages\colorlog\colorlog.py", line 129, in format
    message = super(ColoredFormatter, self).format(record)
  File "F:\PortableApps\Python3x\lib\logging\__init__.py", line 571, in format
    s = self.formatMessage(record)
  File "F:\PortableApps\Python3x\lib\logging\__init__.py", line 540, in formatMessage
    return self._style.format(record)
  File "F:\PortableApps\Python3x\lib\logging\__init__.py", line 392, in format
    return self._fmt.format(**record.__dict__)
KeyError: 'reset'
Call stack:
  File "test.py", line 11, in <module>
    logger.error('TEST')
Message: 'TEST'
Arguments: ()

It seems tarball from https://files.pythonhosted.org/packages/source/c/colorlog/colorlog-4.0.0.tar.gz does not install the LICENSE file by default. Could you change it so the license is installed during setup?

I was trying to figure out how to get the bright colors that Pycharm terminal supports. Took my some time before I released there were undocumented colors, the light_* colors.

I could adjust the documentation for you if you want to added the light_* colors to the README.md, or did you want to do that, or did you want to just leave it as-is?

Figured I would open this up, as it would have saved me a bunch of time if they were in the list of colors.