2016-09-07 3 views
1

Я хотел бы изменить способ отображения сообщений с уровнем DEBUG и INFO при использовании собственного средства ведения журнала Python. Под «изменением» я не имею в виду изменение формата, но добавление дополнительного логического уровня. Например:Как изменить поведение средства ведения журнала Python?

# This is a global variable that is set at the time of initializing the logging. 
required_verbosity_level = 7 

# This variable is passed with each call to the logger. 
supplied_verbosity_level = 5 

Поэтому при создании регистратора мы передаем глобальное требование.

logger = LoggerBridge(required_verbosity_level = 7) 

Затем, когда мы вызываем метод, мы проходим соответствующий уровень:

logger.debug('This is a debug message.', supplied_verbosity_level = 5) 

Так внутренне, логика была бы (5 < 7), и это сделает сообщение видимым из-за тот факт, что значение supplied соответствует required. Однако, в следующем случае:

logger.debug('This is a debug message.', supplied_verbosity_level = 11) 

Сообщение никогда не будет виден как значение supplied выше, чем значение required. Вопрос в следующем: где было бы лучше всего реализовать такое поведение?

Прямо сейчас, я попробовал несколько вещей, основанные на наследование текущего класса Logger и переопределение внутреннего поведения, нечто, известное как mixin подхода:

class LoggerBridge(object): 
    def __init__(self, required_verbosity_level): 
     self.required_verbosity_level = required_verbosity_level 

    def _log_bridge(self, logger): 
     logger(message) 

    def info(self, message, supplied_verbosity_level): 
     if supplied_verbosity_level < self.required_verbosity_level: 
      self._log_bridge(logging.info, message) 

    def debug(self, message, supplied_verbosity_level): 
     if supplied_verbosity_level < self.required_verbosity_level: 
      self._log_bridge(logging.debug, message) 

В теории, это, кажется, работает. Однако, это правильный путь? Есть ли способ решить эту проблему с помощью любого из встроенных битов регистрации, например custom handler или custom filter?

ответ

1

Если все, что вам нужно, это настраиваемые уровни отладки, то поддерживается из коробки. Вы устанавливаете собственный уровень отладки (required_verbosity_level в своем примере) на регистраторе, используя setLevel(), а затем вы используете метод регистрации и пропускаете свой собственный уровень (в вашем примере) log(). Если вы хотите дополнительно настроить эту логику, вы можете переопределить метод isEnabledFor().

+0

Я немного неохотно общаюсь с уровнями. Поскольку это потребовало бы определить уровни явно, и вещи могут выйти из-под контроля с точки зрения совместимости и т. Д. Может быть, я могу каким-то образом использовать 'logging.disable'? – symbolix

+0

@symbolix Что вы подразумеваете под *, для чего требуется явно определить уровни *? Уровни могут быть произвольными целыми числами, и вам не нужно определять какие-либо уровни спереди. 'info (...)' совпадает с вызовом 'log (20, ...)', и вы также можете вызвать 'log (<произвольный_интеграл>, ...)'. Связывание имени уровня с некоторым целым числом с помощью 'addLevelName()' является необязательным. 'logging.disable()' является функцией уровня модуля и действует на всех регистраторов, тогда как в вашем примере вы устанавливаете уровень для одного конкретного логгера. Также я думаю, что у вас есть уровни в вашем примере назад, более высокий уровень должен иметь большее значение. –

+0

Спасибо, я рассмотрю это решение. Я предполагаю, что с целью обучения я могу пойти после решения, которое задало бы это как класс Logger. – symbolix

Смежные вопросы