Python Шаблоны регистрации и БКМ - PullRequest
Новая
       35

Python Шаблоны регистрации и БКМ

0 голосов
/ 30 апреля 2020

Я часто добавляю в свой код множество распечаток журналов, чтобы помочь с профилированием и отладкой или информировать пользователей о проблемах с инструментом, который они запускают.

С этим я также нахожу что у меня будет избыточная печать журналов, каждый со своим контекстом. Например, предположим, что у меня было две функции: 

def sub_function(args):
    logging.info(f"Beginning to look for things that match args: {args}")
    found_arguments = []
    for arg in args:
        logging.info(f"Searching file system for {arg}")
        ...
        if some_value:
            found_arguments.append(some_value)
            logging.info(f"Found value {some_value}!")

    logging.info(f"Found arguments: {found_arguments}")
    return found_arguments

def calling_function(args):
    logging.info(f"Going to search for {args}!")
    result = sub_function(args)
    logging.info("Found arguments: {result}")
    ...

Это может привести к журналу, который выглядит следующим образом: 

Going to search for ["arg1", "arg2"]!
Beginning to look for things that match args: ["arg1", "arg2"]
Searching file system for "arg1"
Searching file system for "arg2"
Found value /tmp/arg2!
Found arguments: ["/tmp/arg2"]
Found arguments: ["/tmp/arg2"]

За исключением того факта, что этот пример будет производить много выходных данных журнала, у этого нет способа отделить контекст для регистрации. Например, разработчику может быть очень интересно узнать, что происходит в sub_function(), и ему не обязательно важно, какие инструменты или внешние calling_function() s могут его использовать.

Но разработчик инструмента хочет генерирует конкретные c сообщения для результатов, и не обязательно заботится о внутренней работе sub_function(), просто у них есть calling_function() и им нужно печатать определенные c сообщения. Пользователи могут расстроиться или даже проигнорировать ведение журнала, если в журнале слишком много «мусора».

Есть ли лучший способ для ведения журнала таким способом? Конечно, я мог бы изменить некоторые журналы на logging.debug() вместо logging.info(), но это требует большой координации между разработчиками на разных уровнях. У одного человека info - у другого человека debug, в конце концов. Единственное, о чем я могу думать, - это реализовать разные регистраторы, но потом я вижу, как они разбиваются на множество разных регистраторов, которые должны иметь возможность перенаправлять вывод в разные места, что может затруднить точное определение разработчиками и пользователями что они увидят, когда запустят инструмент.

Спасибо

...