¿A dónde van las cosas cuando las 'imprimo' desde mi aplicación Django?

Question

Tengo una aplicación Django en un servidor Linux. En una de las vistas, se ejecuta alguna forma del comando print y se imprime alguna cadena. ¿Cómo puedo averiguar cuál fue la cadena impresa? ¿Hay algún registro en el que se guardan estas cosas?

Answer 1

La salida debe estar en la terminal, donde se inició Django. (si no lo inició directamente, no creo que haya una manera de leerlo)

Como lo señaló linklinked, es mejor no usar print, porque esto puede causar Excepciones. Pero esa no es la única razón: hay módulos (como logging) hechos para tales fines y tienen muchas más opciones.

This site (incluso cuando es a partir de 2008) confirman mis declaraciones:

Si usted quiere saber lo que está pasando dentro de un punto de vista, la forma más rápida es dejar caer en un comunicado de impresión. El servidor de desarrollo emite cualquier declaración de impresión directamente al terminal; es la alternativa del servidor a una alerta de JavaScript().

Si desea ser un poco más más sofisticado con su registro, vale la pena recurrir al módulo de registro de Python (parte de la biblioteca estándar). Se puede configurar en su settings.py: aquí se describe, qué hacer (mirada en el sitio)

para la depuración propósitos también se puede habilitar la debug-mode o utilizar el django-debug-toolbar.

Espero que ayude! :)

Answer 2

La impresión muestra hasta bien con "./manage.py de ejecución del servidor" u otras variaciones - como Joschua menciona, se muestra en la terminal donde se inició. Si está ejecutando FCGI desde cron o tal, eso simplemente se vierte en la nada y la pierde por completo.

Para los lugares donde quiero que "impriman", como advertencias o avisos que salgan, utilizo una instancia del registrador de python que empuja a syslog para capturar la salida y colocarla en algún lugar. Yo se crea una instancia de la tala en uno de los módulos, ya que se carga - models.py era el lugar que elegí, simplemente por razones de conveniencia y sabía que siempre se evalúan antes de peticiones llegaron a rodar en

import logging, logging.handlers 

logger = logging.getLogger("djangosyslog") 
hdlr = logging.handlers.SysLogHandler(facility=logging.handlers.SysLogHandler.LOG_DAEMON) 
formatter = logging.Formatter('%(filename)s: %(levelname)s: %(message)s') 
hdlr.setFormatter(formatter) 
logger.addHandler(hdlr) 

. Luego, cuando se desea invocar un mensaje al registrador en sus puntos de vista o lo que sea:

logger = logging.getLogger("djangosyslog") 
logging.warning("Protocol problem: %s", "connection reset", extra=d) 

Hay .Error(), .critical(), y más - investigar http://docs.python.org/library/logging.html para los detalles nitty Gritty.

barra de depuración de Rob Hudson es grande si usted está buscando esa información de depuración - Yo lo uso con frecuencia en el desarrollo mismo. Le proporciona datos sobre la solicitud y respuesta actual, incluido el SQL utilizado para generar cualquier página determinada. Puede inyectar esos datos como una impresión al empujar las cadenas que le interesan al contexto/respuesta, pero me pareció un poco difícil de tratar.

Answer 3

Una advertencia: si intenta implementar código con instrucciones de impresión bajo WSGI, esperar que las cosas se rompen. Use el módulo de registro en su lugar.

Answer 4

Nunca use imprima, ya que una vez que implemente, se imprimirá en stdout y WGSI se romperá.

Utilice logging. Para fines de desarrollo, es realmente fácil de configurar. En su proyecto __init__.py:

import logging 
from django.conf import settings 

fmt = getattr(settings, 'LOG_FORMAT', None) 
lvl = getattr(settings, 'LOG_LEVEL', logging.DEBUG) 

logging.basicConfig(format=fmt, level=lvl) 
logging.debug("Logging started on %s for %s" % (logging.root.name, logging.getLevelName(lvl))) 

Ahora todo lo que se conecte va a stderr, en este caso, su terminal.

logging.debug("Oh hai!") 

Además, puede controlar el nivel de detalle en su settings.py con un ajuste LOG_LEVEL.