En Python, ¿por qué usar el registro en lugar de imprimir?

Para una depuración simple en un proyecto complejo, ¿hay alguna razón para usar el registrador de Python en lugar de imprimir? ¿Qué pasa con otros casos de uso? ¿Existe un mejor caso de uso aceptado para cada uno (especialmente cuando solo busca stdout)?

Siempre he escuchado que esta es una "mejor práctica", pero no he podido averiguar por qué.

El paquete de registro tiene muchas características útiles:

• Es fácil ver dónde y cuándo (incluso desde qué número de línea) se realiza una llamada de registro.
• Puede iniciar sesión en archivos, sockets, prácticamente cualquier cosa, todo al mismo tiempo.
• Puede diferenciar su registro según la gravedad.

Print no tiene ninguno de estos.

Además, si su proyecto está destinado a ser importado por otras herramientas de Python, es una mala práctica que su paquete imprima cosas en stdout, ya que es probable que el usuario no sepa de dónde provienen los mensajes de impresión. Con el registro, los usuarios de su paquete pueden elegir si quieren o no propagar mensajes de registro desde su herramienta o no.

Una de las mayores ventajas del registro adecuado es que puede clasificar los mensajes y activarlos o desactivarlos según lo que necesite. Por ejemplo, podría ser útil activar los mensajes de nivel de depuración para una determinada parte del proyecto, pero atenuarlo para otras partes, para no dejarse llevar por la sobrecarga de información y concentrarse fácilmente en la tarea que necesita. Inicio sesión.

Además, los registros son configurables. Puede filtrarlos fácilmente, enviarlos a archivos, formatearlos, agregar marcas de tiempo y cualquier otra cosa que pueda necesitar a nivel mundial. Los extractos impresos no se gestionan fácilmente.

Las declaraciones impresas son lo peor de ambos mundos , ya que combinan los aspectos negativos de un depurador en línea con la instrumentación de diagnóstico. Tienes que modificar el programa pero no obtienes más código útil de él.

Un depurador en línea le permite inspeccionar el estado de un programa en ejecución; Pero lo bueno de un depurador real es que no es necesario modificar la fuente; ni antes ni después de la sesión de depuración; Simplemente carga el programa en el depurador, dile al depurador dónde quieres buscar y listo.

Instrumentar la aplicación puede requerir algo de trabajo por adelantado, modificando el código fuente de alguna manera, pero la salida de diagnóstico resultante puede tener una enorme cantidad de detalles y se puede activar o desactivar en un grado muy específico. El módulo de registro de Python puede mostrar no solo el mensaje registrado, sino también el archivo y la función que lo llamó, un rastreo si lo hubo, la hora real en que se emitió el mensaje, etc. Más que eso; no es necesario retirar nunca la instrumentación de diagnóstico ; Es tan válido y útil cuando el programa está terminado y en producción como lo fue el día en que se agregó; pero puede tener su salida atascada en un archivo de registro donde no es probable que moleste a nadie, o el nivel de registro se puede bajar para mantener fuera todos los mensajes excepto los más urgentes.

anticipar la necesidad o el uso de un depurador no es realmente más difícil que usar ipython mientras estás probando y familiarizarte con los comandos que utiliza para controlar el depurador pdb integrado.

Cuando piense que una declaración de impresión podría ser más fácil que usar pdb (como suele ser), encontrará que el uso de un registrador lleva su programa a un estado mucho más fácil de trabajar que si usa y luego elimina las declaraciones de impresión .

Tengo mi editor configurado para resaltar declaraciones de impresión como errores de sintaxis y declaraciones de registro como comentarios, ya que así es como las considero.

Si usa el registro, la persona responsable de la implementación puede configurar el registrador para enviarlo a una ubicación personalizada, con información personalizada. Si solo imprime, eso es todo lo que obtienen.

El registro esencialmente crea una base de datos de texto sin formato de búsqueda de salidas de impresión con otros metadatos (marca de tiempo, nivel de registro, número de línea, proceso, etc.).

Esto es oro puro, puedo ejecutar egrep sobre el archivo de registro después de que se haya ejecutado el script de Python. Puedo ajustar mi búsqueda de patrones egrep para elegir exactamente lo que me interesa e ignorar el resto. Esta reducción de la carga cognitiva y la libertad de elegir mi patrón egrep más adelante mediante prueba y error es el beneficio clave para mí.

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

Ahora agregue otras cosas interesantes que la impresión no puede hacer (enviar a socket, establecer niveles de depuración, registrar, agregar metadatos, etc.), tiene todas las razones para preferir el registro en lugar de declaraciones de impresión simples.

Tiendo a usar declaraciones impresas porque es perezoso y fácil, agregar registros necesita algo de código de placa de caldera, oye, tenemos yasnippets (emacs) y ultisnips (vim) y otras herramientas de creación de plantillas, entonces, ¿por qué renunciar al registro para declaraciones simples de impresión?