Come eseguire il debug in Django, nel modo giusto? [chiuso]

Quindi, ho iniziato a imparare a programmare in Python e successivamente in Django . Le prime volte è stato difficile guardare i traceback e in realtà capire cosa ho fatto di sbagliato e dove si trovava l'errore di sintassi. È passato del tempo e in qualche modo lungo la strada, immagino di avere una routine nel debug del mio codice Django. Dato che questo è stato fatto all'inizio della mia esperienza di programmazione, mi sono seduto e mi sono chiesto se come stavo facendo questo fosse inefficace e potesse essere fatto più velocemente. Di solito riesco a trovare e correggere i bug nel mio codice, ma mi chiedo se dovrei farlo più velocemente?

Di solito uso solo le informazioni di debug fornite da Django quando abilitate. Quando le cose finiscono come pensavo, interrompo molto il flusso di codice con un errore di sintassi e guardo le variabili in quel punto nel flusso per capire, dove il codice fa qualcosa di diverso da quello che volevo.

Ma può essere migliorato? Ci sono alcuni buoni strumenti o modi migliori per eseguire il debug del tuo codice Django?

Ci sono molti modi per farlo, ma il più semplice è semplicemente usare il debugger Python . Basta aggiungere la seguente riga a una funzione di visualizzazione Django:

import pdb; pdb.set_trace()

o

breakpoint()  #from Python3.7

Se provi a caricare quella pagina nel tuo browser, il browser si bloccherà e ti verrà richiesto di continuare il debug sull'effettivo codice di esecuzione.

Tuttavia ci sono altre opzioni (non le sto raccomandando):

* return HttpResponse({variable to inspect})

* print {variable to inspect}

* raise Exception({variable to inspect})

Ma il Python Debugger (pdb) è altamente raccomandato per tutti i tipi di codice Python. Se sei già in pdb, dovresti anche dare un'occhiata a IPDB che utilizza ipython per il debug.

Alcune estensioni più utili a pdb sono

pdb ++ , suggerito da Antash .

pudb , suggerito da PatDuJour .

Utilizzo del debugger Python in Django , suggerito da Seafangs .

Mi piace molto il debugger interattivo di Werkzeug . È simile alla pagina di debug di Django, tranne per il fatto che ottieni una shell interattiva a tutti i livelli del traceback. Se si utilizzano le estensioni django , si ottiene un runserver_pluscomando di gestione che avvia il server di sviluppo e fornisce il debugger di Werkzeug su eccezioni.

Ovviamente, dovresti eseguirlo solo localmente, poiché dà a chiunque abbia un browser i diritti per eseguire codice python arbitrario nel contesto del server.

Una piccola sveltina per i tag modello:

@register.filter 
def pdb(element):
    import pdb; pdb.set_trace()
    return element

Ora, all'interno di un modello puoi fare {{ template_var|pdb }}ed entrare in una sessione pdb (dato che stai eseguendo il server di sviluppo locale) dove puoi ispezionare elementil contenuto del tuo cuore.

È un modo molto carino per vedere cosa è successo al tuo oggetto quando arriva al modello.

Esistono alcuni strumenti che collaborano bene e possono semplificare l'attività di debug.

La più importante è la barra degli strumenti di debug di Django .

Quindi hai bisogno di una buona registrazione usando la funzione di registrazione di Python . È possibile inviare l'output della registrazione a un file di registro, ma un'opzione più semplice è l'invio dell'output del registro a Firepython . Per utilizzare questo è necessario utilizzare il browser Firefox con l' estensione firebug . Firepython include un plug-in firebug che visualizzerà qualsiasi registrazione sul lato server in una scheda Firebug.

Firebug stesso è anche fondamentale per il debug del lato Javascript di qualsiasi app che sviluppi. (Supponendo che tu abbia un codice JS ovviamente).

Mi è piaciuto anche django-viewtools per il debug interattivo delle viste usando pdb, ma non lo uso molto.

Esistono strumenti più utili come il bulldozer per rintracciare le perdite di memoria (ci sono anche altri buoni suggerimenti forniti nelle risposte qui su SO per il tracciamento della memoria).

Uso PyCharm (stesso motore Pydev di Eclipse). Mi aiuta davvero a essere visivamente in grado di scorrere il mio codice e vedere cosa sta succedendo.

Quasi tutto è stato menzionato finora, quindi aggiungerò solo che invece di pdb.set_trace()uno è possibile utilizzare ipdb.set_trace () che utilizza iPython e quindi è più potente (completamento automatico e altri gadget). Ciò richiede il pacchetto ipdb, quindi è sufficientepip install ipdb

Ho spinto django-pdbverso PyPI . È un'app semplice che significa che non è necessario modificare il codice sorgente ogni volta che si desidera entrare in pdb.

L'installazione è solo ...

1. pip install django-pdb
2. Aggiungi 'django_pdb'al tuoINSTALLED_APPS

Ora puoi eseguire: manage.py runserver --pdbper entrare in pdb all'inizio di ogni vista ...

bash: manage.py runserver --pdb
Validating models...

0 errors found
Django version 1.3, using settings 'testproject.settings'
Development server is running at http://127.0.0.1:8000/
Quit the server with CONTROL-C.

GET /
function "myview" in testapp/views.py:6
args: ()
kwargs: {}

> /Users/tom/github/django-pdb/testproject/testapp/views.py(7)myview()
-> a = 1
(Pdb)

Ed esegui: manage.py test --pdbper entrare in pdb in caso di test / errori ...

bash: manage.py test testapp --pdb
Creating test database for alias 'default'...
E
======================================================================
>>> test_error (testapp.tests.SimpleTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File ".../django-pdb/testproject/testapp/tests.py", line 16, in test_error
    one_plus_one = four
NameError: global name 'four' is not defined
======================================================================

> /Users/tom/github/django-pdb/testproject/testapp/tests.py(16)test_error()
-> one_plus_one = four
(Pdb)

Il progetto è ospitato su GitHub , ovviamente i contributi sono benvenuti.

Il modo più semplice per eseguire il debug di Python, in particolare per i programmatori utilizzati in Visual Studio, è utilizzare PTVS (Python Tools per Visual Studio). I passaggi sono semplici:

1. Scaricalo e installalo da http://pytools.codeplex.com/
2. Impostare i punti di interruzione e premere F5.
3. Il punto di interruzione viene raggiunto, è possibile visualizzare / modificare le variabili con la stessa facilità del debug dei programmi C # / C ++.
4. È tutto :)

Se desideri eseguire il debug di Django utilizzando PTVS, devi eseguire le seguenti operazioni:

1. In Impostazioni progetto - scheda Generale, imposta "File di avvio" su "manage.py", il punto di ingresso del programma Django.
2. In Impostazioni progetto - scheda Debug, imposta "Argomenti script" su "RunServer --Noreload". Il punto chiave è "--noreload" qui. Se non lo imposti, i tuoi punti di interruzione non verranno colpiti.
3. Divertirsi.

Uso pyDev con Eclipse davvero bene, imposto punti di interruzione, passo nel codice, visualizzo i valori su qualsiasi oggetto e variabile, provo.

Uso PyCharm e lo sostengo fino in fondo. Mi è costato un po ', ma devo dire che il vantaggio che ne ricavo non ha prezzo. Ho provato a eseguire il debug dalla console e do molto credito alle persone che possono farlo, ma per me riuscire a eseguire il debug visivo delle mie applicazioni è fantastico.

Devo dire però che PyCharm ha molta memoria. Ma poi di nuovo, niente di buono è libero nella vita. Sono appena arrivati ​​con la loro ultima versione 3. Funziona molto bene anche con Django, Flask e Google AppEngine. Quindi, nel complesso, direi che è un ottimo strumento utile per qualsiasi sviluppatore.

Se non lo stai ancora utilizzando, ti consiglio di ottenere la versione di prova per 30 giorni per dare un'occhiata alla potenza di PyCharm. Sono sicuro che ci sono anche altri strumenti disponibili, come Aptana. Ma credo che mi piaccia anche l'aspetto di PyCharm. Mi sento molto a mio agio nel debug delle mie app lì.

A volte, quando desidero esplorare un determinato metodo ed evocare pdb è troppo ingombrante, aggiungerei:

import IPython; IPython.embed()

IPython.embed() avvia una shell IPython che ha accesso alle variabili locali dal punto in cui viene chiamata.

Dal mio punto di vista, potremmo suddividere le attività comuni di debug del codice in tre modelli di utilizzo distinti:

1. Qualcosa ha sollevato un'eccezione : il debugger Werkzeug di correerver_plus in soccorso. La capacità di eseguire codice personalizzato a tutti i livelli di traccia è un killer. E se sei completamente bloccato, puoi creare un Gist da condividere con un solo clic.
2. La pagina viene visualizzata, ma il risultato è errato : di nuovo, Werkzeug oscilla. Per creare un punto di interruzione nel codice, digita semplicemente assert Falseil punto in cui vuoi fermarti.
3. Il codice funziona male , ma l'aspetto rapido non aiuta. Molto probabilmente, un problema algoritmico. Sospiro. Allora io di solito fuoco fino una console debugger PuDB : import pudb; pudb.set_trace(). Il vantaggio principale rispetto a [i] pdb è che PuDB (guardando come se fossi negli anni '80) rende l'impostazione delle espressioni dell'orologio personalizzate un gioco da ragazzi. E il debug di un mucchio di loop nidificati è molto più semplice con una GUI.

Ah, sì, i problemi dei modelli. Il problema più comune (per me e i miei colleghi) è un contesto sbagliato: o non hai una variabile o la tua variabile non ha alcun attributo. Se stai utilizzando la barra degli strumenti di debug , controlla il contesto nella sezione "Modelli" o, se non è sufficiente, imposta un'interruzione nel codice delle viste appena dopo aver riempito il contesto.

Così è andata.

Consiglio vivamente epdb (Extended Python Debugger).

https://bitbucket.org/dugan/epdb

Una cosa che adoro di epdb per il debug di Django o di altri server web Python è il comando epdb.serve (). Questo imposta una traccia e serve questo su una porta locale a cui è possibile connettersi. Caso d'uso tipico:

Ho una visione che voglio seguire passo per passo. Inserirò quanto segue nel punto in cui voglio impostare la traccia.

import epdb; epdb.serve()

Una volta eseguito questo codice, apro un interprete Python e mi collego all'istanza di servizio. Posso analizzare tutti i valori e scorrere il codice usando i comandi pdb standard come n, s, ecc.

In [2]: import epdb; epdb.connect()
(Epdb) request
<WSGIRequest
path:/foo,
GET:<QueryDict: {}>, 
POST:<QuestDict: {}>,
...
>
(Epdb) request.session.session_key
'i31kq7lljj3up5v7hbw9cff0rga2vlq5'
(Epdb) list
 85         raise some_error.CustomError()
 86 
 87     # Example login view
 88     def login(request, username, password):
 89         import epdb; epdb.serve()
 90  ->     return my_login_method(username, password)
 91
 92     # Example view to show session key
 93     def get_session_key(request):
 94         return request.session.session_key
 95

E tonnellate in più che puoi imparare a scrivere in aiuto epdb in qualsiasi momento.

Se vuoi servire o connetterti a più istanze epdb contemporaneamente, puoi specificare la porta su cui ascoltare (il valore predefinito è 8080). ie

import epdb; epdb.serve(4242)

>> import epdb; epdb.connect(host='192.168.3.2', port=4242)

l'host è impostato su "localhost" se non specificato. L'ho inserito qui per dimostrare come è possibile utilizzarlo per eseguire il debug di qualcosa di diverso da un'istanza locale, come un server di sviluppo sulla LAN locale. Ovviamente, se lo fai, fai attenzione che la traccia impostata non arrivi mai sul tuo server di produzione!

Come nota veloce, puoi ancora fare la stessa cosa della risposta accettata con epdb ( import epdb; epdb.set_trace()) ma volevo evidenziare la funzionalità di servizio poiché l'ho trovata così utile.

Ho appena trovato wdb ( http://www.rkblog.rk.edu.pl/w/p/debugging-python-code-browser-wdb-debugger/?goback=%2Egde_25827_member_255996401 ). Ha un'interfaccia utente / GUI piuttosto carina con tutte le campane e fischietti. L'autore dice questo su wdb -

"Esistono IDE come PyCharm che hanno i propri debugger. Offrono un set di funzioni simili o uguali ... Comunque per usarli devi usare quegli IDE specifici (e alcuni di essi non sono gratuiti o potrebbero non essere disponibili per tutti piattaforme). Scegli lo strumento giusto per le tue esigenze. "

Ho pensato di passarlo.

Anche un articolo molto utile sui debugger di Python: https://zapier.com/engineering/debugging-python-boss/

Infine , se desideri vedere una bella stampa grafica del tuo stack di chiamate in Django, controlla: https://github.com/joerick/pyinstrument . Aggiungi semplicemente pyinstrument.middleware.ProfilerMiddleware a MIDDLEWARE_CLASSES, quindi aggiungi il profilo? Alla fine dell'URL della richiesta per attivare il profiler.

Può anche eseguire pyinstrument dalla riga di comando o importando come modulo.

Aggiungi import pdb; pdb.set_trace()o breakpoint() (form python3.7) alla riga corrispondente nel codice Python ed eseguilo . L'esecuzione si interromperà con una shell interattiva. Nella shell è possibile eseguire il codice Python (ovvero stampare variabili) o usare comandi come:

• c continuare l'esecuzione
• n passa alla riga successiva all'interno della stessa funzione
• s passa alla riga successiva in questa funzione o in una funzione chiamata
• q chiudere il debugger / esecuzione

Vedi anche: https://poweruser.blog/setting-a-breakpoint-in-python-438e23fe6b28

Una delle migliori opzioni per il debug del codice Django è tramite wdb: https://github.com/Kozea/wdb

wdb funziona con python 2 (2.6, 2.7), python 3 (3.2, 3.3, 3.4, 3.5) e pypy. Ancora meglio, è possibile eseguire il debug di un programma Python 2 con un server WDB in esecuzione su Python 3 e viceversa o eseguire il debug di un programma in esecuzione su un computer con un server di debug in esecuzione su un altro computer all'interno di una pagina Web su un terzo computer! Ancora meglio, ora è possibile mettere in pausa un processo / thread python attualmente in esecuzione usando l'iniezione di codice dall'interfaccia web. (Questo richiede gdb e ptrace abilitati) In altre parole è una versione molto migliorata di pdb direttamente nel tuo browser con belle funzionalità.

Installa ed esegui il server e nel tuo codice aggiungi:

import wdb
wdb.set_trace()

Secondo l'autore, le principali differenze rispetto a pdbsono:

Per coloro che non conoscono il progetto, wdb è un debugger python come pdb, ma con un front-end Web lucido e molte funzionalità aggiuntive, come:

• Evidenziazione della sintassi di origine
• Punti di interruzione visivi
• Completamento del codice interattivo tramite jedi
• Punti di interruzione persistenti
• Ispezione di oggetti profondi mediante il supporto del mouse Multithreading / Multiprocessing
• Debug remoto
• Guarda le espressioni
• Nell'edizione del codice di debugger
• Integrazione di server Web diffusi per interrompere l'errore
• Ad eccezione della rottura durante trace (non post-mortem) contrariamente al debugger di werkzeug, ad esempio
• Interruzione dei programmi attualmente in esecuzione tramite iniezione di codice (su sistemi supportati)

Ha un'ottima interfaccia utente basata su browser. Una gioia da usare! :)

Uso PyCharm e diversi strumenti di debug. Inoltre, fai in modo che siano disponibili articoli carini su come configurare facilmente queste cose per i principianti. Puoi iniziare qui. Descrive il debug di PDB e GUI in generale con progetti Django. Spero che qualcuno ne trarrebbe beneficio.

Se usi Aptana per lo sviluppo di django, guarda questo: http://www.youtube.com/watch?v=qQh-UQFltJQ

In caso contrario, considera l'utilizzo.

La maggior parte delle opzioni sono già citate. Per stampare il contesto del modello, ho creato una semplice libreria per quello. Vedi https://github.com/edoburu/django-debugtools

Puoi usarlo per stampare il contesto del modello senza alcun {% load %}costrutto:

{% print var %}   prints variable
{% print %}       prints all

Utilizza un formato pprint personalizzato per visualizzare le variabili in un <pre>tag.

Trovo che Visual Studio Code sia fantastico per il debug delle app Django. I parametri standard di python launch.json vengono eseguiti python manage.pycon il debugger collegato, in modo da poter impostare i punti di interruzione e scorrere il codice come preferisci.

Per coloro che possono accidentalmente aggiungere pdb in commit live, posso suggerire questa estensione di risposta #Koobz:

@register.filter 
def pdb(element):
    from django.conf import settings
    if settings.DEBUG:    
        import pdb
        pdb.set_trace()
    return element

Dalla mia esperienza, ci sono due modi:

1. usa ipdb , che è un debugger avanzato come pdb.

   import ipdb;ipdb.set_trace()o breakpoint() (da python3.7)

2. usa la shell django, usa il comando qui sotto. Questo è molto utile quando stai sviluppando una nuova vista.

   python manage.py shell

consiglio vivamente di usare PDB.

import pdb
pdb.set_trace()

È possibile ispezionare tutti i valori delle variabili, accedere alla funzione e molto altro. https://docs.python.org/2/library/pdb.html

per controllare tutti i tipi di richiesta, risposta e hit nel database. Sto usando django-debug-toolbar https://github.com/django-debug-toolbar/django-debug-toolbar

Come menzionato in altri post qui - impostare punti di interruzione nel tuo codice e passare attraverso il codice per vedere se si comporta come ti aspettavi è un ottimo modo per imparare qualcosa come Django fino a quando non hai un buon senso di come tutto si comporta - e quale codice sta facendo.

Per fare ciò, consiglierei di usare WingIde. Proprio come gli altri IDE citati, belli e facili da usare, un layout piacevole e anche facili da impostare i punti di interruzione valutano / modificano lo stack, ecc. Perfetto per visualizzare cosa sta facendo il codice mentre lo attraversi. Ne sono un grande fan.

Anche io uso PyCharm - ha un'eccellente analisi del codice statico e può aiutare a volte a individuare i problemi prima di rendersi conto che sono lì.

Come già detto django-debug-toolbar è essenziale - https://github.com/django-debug-toolbar/django-debug-toolbar

E pur non essendo esplicitamente uno strumento di debug o di analisi, uno dei miei preferiti è il SQL Printing Middleware disponibile da Django Snippets su https://djangosnippets.org/snippets/290/

Verranno visualizzate le query SQL generate dalla visualizzazione. Questo ti darà un'idea di cosa sta facendo l'ORM e se le tue domande sono efficienti o devi rielaborare il tuo codice (o aggiungere la cache).

Lo trovo prezioso per tenere d'occhio le prestazioni delle query durante lo sviluppo e il debug della mia applicazione.

Solo un altro suggerimento: l'ho modificato leggermente per uso personale per mostrare solo il riepilogo e non l'istruzione SQL .... Quindi lo uso sempre durante lo sviluppo e il test. Ho anche aggiunto che se len (connection.queries) è maggiore di una soglia predefinita, verrà visualizzato un avviso aggiuntivo.

Quindi, se noto qualcosa di brutto (dal punto di vista delle prestazioni o del numero di query), accendo la visualizzazione completa delle istruzioni SQL per vedere esattamente cosa sta succedendo. Molto utile quando lavori su un grande progetto Django con più sviluppatori.

usare pdbo ipdb. La differenza tra questi due è che ipdb supporta il completamento automatico.

per pdb

import pdb
pdb.set_trace()

per ipdb

import ipdb
ipdb.set_trace()

Per eseguire un nuovo ntasto per la battuta della linea , per continuare il ctasto per colpire . controlla più opzioni usandohelp(pdb)

Un suggerimento aggiuntivo.

È possibile sfruttare nosetests e PDB insieme, piuttosto iniettando pdb.set_trace()nelle viste manualmente. Il vantaggio è che è possibile osservare le condizioni di errore al primo avvio, potenzialmente nel codice di terze parti.

Ecco un errore per me oggi.

TypeError at /db/hcm91dmo/catalog/records/

render_option() argument after * must be a sequence, not int

....


Error during template rendering

In template /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/crispy_forms/templates/bootstrap3/field.html, error at line 28
render_option() argument after * must be a sequence, not int
18  
19          {% if field|is_checkboxselectmultiple %}
20              {% include 'bootstrap3/layout/checkboxselectmultiple.html' %}
21          {% endif %}
22  
23          {% if field|is_radioselect %}
24              {% include 'bootstrap3/layout/radioselect.html' %}
25          {% endif %}
26  
27          {% if not field|is_checkboxselectmultiple and not field|is_radioselect %}
28  

      {% if field|is_checkbox and form_show_labels %}

Ora, so che questo significa che ho preso in giro il costruttore per il modulo e ho anche una buona idea di quale campo è un problema. Ma posso usare pdb per vedere quali forme croccanti si lamentano all'interno di un modello ?

Sì posso. Utilizzando l' --pdb opzione nosetests:

tests$ nosetests test_urls_catalog.py --pdb

Non appena raggiungo un'eccezione (comprese quelle gestite con garbo), pdb si interrompe dove succede e posso guardarmi intorno.

  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/forms/forms.py", line 537, in __str__
    return self.as_widget()
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/forms/forms.py", line 593, in as_widget
    return force_text(widget.render(name, self.value(), attrs=attrs))
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/forms/widgets.py", line 513, in render
    options = self.render_options(choices, [value])
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/forms/widgets.py", line 543, in render_options
    output.append(self.render_option(selected_choices, *option))
TypeError: render_option() argument after * must be a sequence, not int
INFO lib.capture_middleware log write_to_index(http://localhost:8082/db/hcm91dmo/catalog/records.html)
INFO lib.capture_middleware log write_to_index:end
> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/forms/widgets.py(543)render_options()
-> output.append(self.render_option(selected_choices, *option))
(Pdb) import pprint
(Pdb) pprint.PrettyPrinter(indent=4).pprint(self)
<django.forms.widgets.Select object at 0x115fe7d10>
(Pdb) pprint.PrettyPrinter(indent=4).pprint(vars(self))
{   'attrs': {   'class': 'select form-control'},
    'choices': [[('_', 'any type'), (7, (7, 'type 7', 'RECTYPE_TABLE'))]],
    'is_required': False}
(Pdb)         

Ora, è chiaro che il mio argomento di scelta per il costruttore di campi croccanti era come un elenco all'interno di un elenco, piuttosto che un elenco / tupla di tuple.

 'choices': [[('_', 'any type'), (7, (7, 'type 7', 'RECTYPE_TABLE'))]]

La cosa bella è che questo pdb si svolge nel codice di Crispy, non nel mio e non ho avuto bisogno di inserirlo manualmente.

Durante lo sviluppo, aggiungendo un rapido

assert False, value

può aiutare a diagnosticare problemi nelle viste o in qualsiasi altro luogo, senza la necessità di utilizzare un debugger.