Em python, por que usar registro em vez de impressão?

Para depuração simples em um projeto complexo, há uma razão para usar o logger python em vez de imprimir? E quanto a outros casos de uso? Existe um melhor caso de uso aceito para cada um (especialmente quando você está procurando apenas por stdout)?

Sempre ouvi dizer que essa é uma "prática recomendada", mas não consegui descobrir o porquê.

O pacote de registro tem muitos recursos úteis:

• Fácil de ver onde e quando (até mesmo de qual número de linha) uma chamada de registro está sendo feita.
• Você pode registrar em arquivos, sockets, praticamente qualquer coisa, tudo ao mesmo tempo.
• Você pode diferenciar seu registro com base na gravidade.

A impressão não tem nenhum desses.

Além disso, se o seu projeto deve ser importado por outras ferramentas Python, é uma prática ruim que o seu pacote imprima coisas no stdout, já que o usuário provavelmente não saberá de onde vêm as mensagens de impressão. Com o registro, os usuários de seu pacote podem escolher se desejam ou não propagar mensagens de registro de sua ferramenta.

Uma das maiores vantagens do registro adequado é que você pode categorizar as mensagens e ativá-las ou desativá-las, dependendo do que for necessário. Por exemplo, pode ser útil ativar as mensagens de nível de depuração para uma determinada parte do projeto, mas diminuí-las para outras partes, de modo a não ser assumido pela sobrecarga de informações e se concentrar facilmente na tarefa para a qual você precisa exploração madeireira.

Além disso, os logs são configuráveis. Você pode facilmente filtrá-los, enviá-los para arquivos, formatá-los, adicionar carimbos de data / hora e qualquer outra coisa que você possa precisar em uma base global. As declarações de impressão não são facilmente gerenciadas.

As declarações impressas são o pior dos dois mundos , combinando os aspectos negativos de um depurador online com instrumentação de diagnóstico. Você tem que modificar o programa, mas não obtém mais códigos úteis dele.

Um depurador online permite que você inspecione o estado de um programa em execução; Mas o bom de um depurador real é que você não precisa modificar o código-fonte; nem antes nem depois da sessão de depuração; Você apenas carrega o programa no depurador, diz ao depurador onde deseja olhar e está tudo pronto.

Instrumentar o aplicativo pode exigir algum trabalho inicial, modificar o código-fonte de alguma forma, mas a saída de diagnóstico resultante pode ter uma quantidade enorme de detalhes e pode ser ativada ou desativada em um grau muito específico. O módulo de registro do python pode mostrar não apenas a mensagem registrada, mas também o arquivo e a função que a chamou, um rastreamento, se houver, a hora real em que a mensagem foi emitida e assim por diante. Mais que isso; necessidade de instrumentação de diagnóstico nunca ser removida; É tão válido e útil quando o programa está concluído e em produção quanto no dia em que foi adicionado; mas pode ter sua saída presa em um arquivo de log, onde provavelmente não incomodará ninguém, ou o nível de log pode ser reduzido para manter todas as mensagens, exceto as mais urgentes.

prever a necessidade ou o uso de um depurador não é realmente mais difícil do que usar ipython durante o teste e se familiarizar com os comandos que ele usa para controlar o depurador pdb embutido.

Quando você se pegar pensando que uma instrução de impressão pode ser mais fácil do que usar pdb (como costuma ser), você descobrirá que usar um logger torna seu programa muito mais fácil de trabalhar do que se você usar e remover posteriormente as instruções de impressão .

Tenho meu editor configurado para destacar as instruções de impressão como erros de sintaxe e as instruções de registro como comentários, uma vez que é assim que as vejo.

Se você usar o log, a pessoa responsável pela implantação pode configurar o logger para enviá-lo a um local personalizado, com informações personalizadas. Se você apenas imprimir, isso é tudo que eles terão.

O registro basicamente cria um banco de dados de texto simples pesquisável de saídas de impressão com outros metadados (carimbo de data / hora, nível de log, número de linha, processo, etc.).

Isso é ouro puro, posso executar egrep sobre o arquivo de log após a execução do script python. Posso ajustar minha pesquisa de padrão egrep para escolher exatamente o que estou interessado e ignorar o resto. Essa redução da carga cognitiva e da liberdade de escolher meu padrão egrep mais tarde por tentativa e erro é o principal benefício para mim.

tail -f mylogfile.log | egrep "key_word1|key_word2"

Agora acrescente outras coisas legais que o print não pode fazer (enviar para o socket, definir níveis de depuração, logrotate, adicionar metadados, etc.), você tem todos os motivos para preferir o registro em vez das instruções de impressão simples.

Eu tendo a usar instruções de impressão porque é preguiçoso e fácil, adicionar log requer algum código padrão, ei, nós temos yasnippets (emacs) e ultisnips (vim) e outras ferramentas de modelagem, então por que desistir de log para instruções de impressão simples !?