A veces, la mejor manera de depurar algo es imprimir algunas cosas en la página, y exit(), ¿cómo puedo hacer esto en un sitio de Python/Django?Equivalente a PHP "echo something; exit();" con Python/Django?
p. Ej. en PHP:
echo $var;
exit();
Gracias
poner esto en su función de vista:
from django.http import HttpResponse
return HttpResponse(str(var))
Estoy tratando de hacer esto desde una clase de Middleware' process_request', por lo que una respuesta de Http en ese punto no funcionaría, ¿verdad? – adamJLev
En realidad, después de leer los documentos de Django, parece que si devuelve un HttpRequest, detiene todo lo demás y simplemente lo devuelve. ¡Gracias! – adamJLev
El uso de HttpResponse en realidad terminaría el recordatorio del procesamiento de la vista, ya que el uso de imprimir o agregar al contexto de la plantilla puede ayudarlo a ver los datos que se pasan. Además, si tiene una barra de herramientas de depuración instalada, puede ver todas las variables de contexto pasadas presentadas con pulcritud. – phoenix24
simplemente he querido dar una respuesta alternativa: Sólo tiene que utilizar print declaraciones y servir a su sitio Django con python manage.py runserver
En este caso, las declaraciones print aparecen en su shell y su sitio continúa funcionando como lo haría normalmente aliado.
¡Un gran consejo, gracias! – adamJLev
A menos que esté bloqueado en la depuración a través de Apache (o lo que sea), es difícil superar la inmediatez de ejecutar el servidor de desarrollo y simplemente imprimir() s. A menudo puedo hacer un ciclo de observar, editar, recargar y observar en menos de 20 o 30 segundos. –
Simplemente recuerde eliminar esas instrucciones de impresión cuando haya terminado, ¡dejándolas en crash mod_wsgi! – shacker
Si no desea que se bloquee mod_wsgi en la impresión de hacer esto en su archivo wsgi
sys.stdout = sys.stderr
copias se enviarán a la error_log
No es correcto decir que mod_wsgi 'se bloqueará'. Es el uso de 'print' para stdout que fue incorrecto. El módulo mod_wsgi estaba intentando intencionalmente hacer que escribas aplicaciones WSGI portátiles marcando lo que estabas haciendo como incorrecto. A nadie parece importarle que sus aplicaciones WSGI no sean portátiles y mod_wsgi dejó de intentar hacer lo correcto en mod_wsgi 3.0. En otras palabras, esto no es necesario en mod_wsgi 3.X y posteriores. Lea 'http://blog.dscpl.com.au/2009/04/wsgi-and-printing-to-standard-output.html'. –
Si está utilizando mod_wsgi se puede decir:
La excepción SystemExit en realidad no hará que todo el proceso salga como lo haría normalmente, sino que solo provocará que la solicitud salga, suponiendo que ningún código superior lo detecta y yo gnores.
Asegúrese de estar utilizando mod_wsgi 3.X. Si se utiliza mod_wsgi mayor, lo que tendría que decir en su lugar:
import sys
print >> sys.stderr
raise SystemExit
Otros servidores WSGI también pueden tratar SystemExit en una solicitud de la misma manera, digamos que tendría que experimentar en cuanto a lo que sucede si se utiliza otra solución de alojamiento.
Para otra información sobre la depuración de aplicaciones WSGI leer:
por qué no usar 'morir $ var;' en el primer lugar? – knittl
Estaba tratando de ser lo más claro posible en caso de que un posible "contestador de preguntas de Python" no supiera que 'die == exit' :) – adamJLev