Wie kann man in Django debuggen? [geschlossen]

Also fing ich an, in Python und später in Django das Codieren zu lernen . Das erste Mal war es schwierig, Rückverfolgungen zu betrachten und tatsächlich herauszufinden, was ich falsch gemacht habe und wo der Syntaxfehler war. Einige Zeit ist vergangen und irgendwann habe ich eine Routine beim Debuggen meines Django-Codes. Da dies zu Beginn meiner Codierungserfahrung gemacht wurde, setzte ich mich hin und fragte mich, ob meine Vorgehensweise ineffektiv war und schneller durchgeführt werden konnte. Normalerweise schaffe ich es, die Fehler in meinem Code zu finden und zu korrigieren, aber ich frage mich, ob ich es schneller machen sollte.

Normalerweise verwende ich nur die Debug-Informationen, die Django gibt, wenn sie aktiviert sind. Wenn die Dinge so enden, wie ich es mir vorgestellt habe, unterbreche ich den Code-Fluss häufig mit einem Syntaxfehler und schaue mir die Variablen an diesem Punkt im Fluss an, um herauszufinden, wo der Code etwas anderes tut als ich wollte.

Aber kann das verbessert werden? Gibt es einige gute Tools oder bessere Möglichkeiten, um Ihren Django-Code zu debuggen?

Es gibt eine Reihe von Möglichkeiten, aber am einfachsten ist es, einfach den Python-Debugger zu verwenden . Fügen Sie einer Django-Ansichtsfunktion einfach die folgende Zeile hinzu:

import pdb; pdb.set_trace()

oder

breakpoint()  #from Python3.7

Wenn Sie versuchen, diese Seite in Ihren Browser zu laden, bleibt der Browser hängen und Sie werden aufgefordert, das Debuggen des tatsächlich ausgeführten Codes fortzusetzen.

Es gibt jedoch andere Optionen (ich empfehle sie nicht):

* return HttpResponse({variable to inspect})

* print {variable to inspect}

* raise Exception({variable to inspect})

Der Python-Debugger (pdb) wird jedoch für alle Arten von Python-Code dringend empfohlen. Wenn Sie bereits mit pdb beschäftigt sind, sollten Sie sich auch IPDB ansehen , die ipython zum Debuggen verwendet.

Einige weitere nützliche Erweiterungen für pdb sind

pdb ++ , vorgeschlagen von Antash .

pudb , vorgeschlagen von PatDuJour .

Verwendung des Python-Debuggers in Django , vorgeschlagen von Seafangs .

Ich mag den interaktiven Debugger von Werkzeug sehr . Es ähnelt der Debug-Seite von Django, außer dass Sie auf jeder Ebene des Tracebacks eine interaktive Shell erhalten. Wenn Sie die Django-Erweiterungen verwenden , erhalten Sie einen runserver_plusVerwaltungsbefehl, der den Entwicklungsserver startet und Ihnen den Tool- Debugger für Ausnahmen gibt.

Natürlich sollten Sie dies nur lokal ausführen, da es jedem mit einem Browser die Rechte gibt, beliebigen Python-Code im Kontext des Servers auszuführen.

Ein kleiner Quickie für Template-Tags:

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

Jetzt können Sie in einer Vorlage {{ template_var|pdb }}eine PDF-Sitzung durchführen (vorausgesetzt, Sie führen den lokalen Entwicklungsserver aus), in der Sie elementnach Herzenslust nachsehen können .

Auf diese Weise können Sie sehen, was mit Ihrem Objekt passiert ist, wenn es bei der Vorlage ankommt.

Es gibt einige Tools, die gut zusammenarbeiten und Ihre Debugging-Aufgabe erleichtern können.

Am wichtigsten ist die Django-Debug-Symbolleiste .

Dann benötigen Sie eine gute Protokollierung mit der Python- Protokollierungsfunktion . Sie können die Protokollausgabe an eine Protokolldatei senden. Eine einfachere Option ist jedoch das Senden der Protokollausgabe an Firepython . Um dies zu verwenden, müssen Sie den Firefox-Browser mit der Firebug- Erweiterung verwenden. Firepython enthält ein Firebug-Plugin, das alle serverseitigen Protokollierungen auf einer Firebug-Registerkarte anzeigt.

Firebug selbst ist auch wichtig für das Debuggen der Javascript-Seite jeder von Ihnen entwickelten App. (Vorausgesetzt, Sie haben natürlich JS-Code).

Ich mochte auch Django-Viewtools zum interaktiven Debuggen von Ansichten mit pdb, aber ich benutze es nicht so oft.

Es gibt nützlichere Tools wie Dozer zum Aufspüren von Speicherlecks (es gibt auch andere gute Vorschläge in den Antworten hier auf SO für das Aufspüren von Speicher).

Ich benutze PyCharm (dieselbe Pydev-Engine wie Eclipse). Hilft mir wirklich, visuell in der Lage zu sein, meinen Code zu durchlaufen und zu sehen, was passiert.

Fast alles wurde bisher erwähnt, so dass ich nur dass statt hinzufügen würde pdb.set_trace()man verwenden ipdb.set_trace () , die ipython verwendet und daher ist mächtiger ( die automatische Vervollständigung und andere Leckereien). Dies erfordert ein ipdb-Paket, das Sie also nur benötigenpip install ipdb

Ich habe django-pdbzu PyPI geschoben . Es ist eine einfache App, die bedeutet, dass Sie Ihren Quellcode nicht jedes Mal bearbeiten müssen, wenn Sie in pdb einbrechen möchten.

Die Installation ist nur ...

1. pip install django-pdb
2. Fügen Sie 'django_pdb'Ihrem hinzuINSTALLED_APPS

Sie können jetzt ausführen: manage.py runserver --pdbzu Beginn jeder Ansicht in pdb einbrechen ...

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)

Und führen Sie aus: manage.py test --pdbum bei Testfehlern / -fehlern in pdb einzubrechen ...

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)

Das Projekt wird auf GitHub gehostet , Beiträge sind natürlich willkommen.

Der einfachste Weg, Python zu debuggen - insbesondere für Programmierer, die an Visual Studio gewöhnt sind - ist die Verwendung von PTVS (Python Tools for Visual Studio). Die Schritte sind einfach:

1. Laden Sie es von http://pytools.codeplex.com/ herunter und installieren Sie es.
2. Setzen Sie Haltepunkte und drücken Sie F5.
3. Wenn Ihr Haltepunkt erreicht ist, können Sie die Variablen so einfach anzeigen / ändern wie das Debuggen von C # / C ++ - Programmen.
4. Das ist alles :)

Wenn Sie Django mit PTVS debuggen möchten, müssen Sie Folgendes tun:

1. Setzen Sie auf der Registerkarte Projekteinstellungen - Allgemein die Option "Startdatei" auf "manage.py", den Einstiegspunkt des Django-Programms.
2. Setzen Sie auf der Registerkarte Projekteinstellungen - Debuggen "Skriptargumente" auf "runserver --noreload". Der entscheidende Punkt ist hier das "--noreload". Wenn Sie es nicht festlegen, werden Ihre Haltepunkte nicht erreicht.
3. Geniesse es.

Ich benutze pyDev mit Eclipse wirklich gut, setze Haltepunkte , gehe in den Code, zeige Werte für Objekte und Variablen an und probiere es aus.

Ich benutze PyCharm und stehe den ganzen Weg dazu. Es hat mich ein wenig gekostet, aber ich muss sagen, dass der Vorteil, den ich daraus ziehe, von unschätzbarem Wert ist. Ich habe versucht, über die Konsole zu debuggen, und ich gebe den Leuten viel Anerkennung dafür, wer das kann, aber für mich ist es großartig, meine Anwendung (en) visuell zu debuggen.

Ich muss allerdings sagen, PyCharm viel Speicher benötigt. Andererseits ist nichts Gutes im Leben frei. Sie kamen gerade mit ihrer neuesten Version 3. Sie funktioniert auch sehr gut mit Django, Flask und Google AppEngine. Alles in allem würde ich sagen, dass es ein großartiges praktisches Tool für jeden Entwickler ist.

Wenn Sie es noch nicht verwenden, würde ich empfehlen, die Testversion 30 Tage lang zu erwerben, um einen Blick auf die Leistungsfähigkeit von PyCharm zu werfen. Ich bin sicher, dass es auch andere Tools gibt, wie zum Beispiel Aptana. Aber ich denke, ich mag auch das Aussehen von PyCharm. Ich fühle mich sehr wohl, wenn ich meine Apps dort debugge.

Manchmal, wenn ich mich mit einer bestimmten Methode beschäftigen möchte und das Beschwören von PDFs einfach zu umständlich ist, würde ich hinzufügen:

import IPython; IPython.embed()

IPython.embed() Startet eine IPython-Shell, die ab dem Punkt, an dem Sie sie aufrufen, Zugriff auf die lokalen Variablen hat.

Aus meiner Sicht könnten wir allgemeine Code-Debugging- Aufgaben in drei verschiedene Verwendungsmuster unterteilen:

1. Etwas hat eine Ausnahme ausgelöst : runserver_plus 'Werkzeug-Debugger zur Rettung. Die Möglichkeit, benutzerdefinierten Code auf allen Trace-Ebenen auszuführen, ist ein Killer. Und wenn Sie nicht weiterkommen, können Sie einen Gist erstellen, den Sie mit nur einem Klick teilen können.
2. Seite wird gerendert, aber das Ergebnis ist falsch : Wieder rockt Werkzeug. Um einen Haltepunkt im Code festzulegen, geben Sie einfach assert Falsedie Stelle ein, an der Sie anhalten möchten.
3. Code funktioniert falsch , aber der schnelle Blick hilft nicht. Höchstwahrscheinlich ein algorithmisches Problem. Seufzer. Dann starte ich normalerweise einen Konsolen-Debugger PuDB : import pudb; pudb.set_trace(). Der Hauptvorteil gegenüber [i] pdb ist, dass PuDB (während Sie wie in den 80ern aussehen) das Festlegen von benutzerdefinierten Uhrenausdrücken zum Kinderspiel macht. Das Debuggen einer Reihe verschachtelter Schleifen ist mit einer GUI viel einfacher.

Ach ja, die Probleme der Vorlagen. Das häufigste Problem (für mich und meine Kollegen) ist ein falscher Kontext: Entweder haben Sie keine Variable oder Ihre Variable hat kein Attribut. Wenn Sie die Debug-Symbolleiste verwenden , überprüfen Sie einfach den Kontext im Abschnitt "Vorlagen" oder setzen Sie, falls dies nicht ausreicht, eine Unterbrechung im Code Ihrer Ansichten, sobald Ihr Kontext gefüllt ist.

So geht es.

Ich kann epdb (Extended Python Debugger) nur empfehlen.

https://bitbucket.org/dugan/epdb

Eine Sache, die ich an epdb zum Debuggen von Django oder anderen Python-Webservern liebe, ist der Befehl epdb.serve (). Dadurch wird eine Ablaufverfolgung festgelegt und an einem lokalen Port bereitgestellt, zu dem Sie eine Verbindung herstellen können. Typischer Anwendungsfall:

Ich habe die Ansicht, dass ich Schritt für Schritt durchgehen möchte. Ich werde an der Stelle, an der ich die Ablaufverfolgung festlegen möchte, Folgendes einfügen.

import epdb; epdb.serve()

Sobald dieser Code ausgeführt wird, öffne ich einen Python-Interpreter und verbinde mich mit der Serving-Instanz. Ich kann alle Werte analysieren und den Code mit den Standard-pdb-Befehlen wie n, s usw. durchlaufen.

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

Und jede Menge mehr, die Sie jederzeit über das Schreiben von epdb-Hilfe lernen können.

Wenn Sie mehrere epdb-Instanzen gleichzeitig bedienen oder eine Verbindung herstellen möchten, können Sie den Port angeben, der überwacht werden soll (Standard ist 8080). Dh

import epdb; epdb.serve(4242)

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

Der Host ist standardmäßig 'localhost', falls nicht angegeben. Ich habe es hier reingeworfen, um zu demonstrieren, wie Sie damit etwas anderes als eine lokale Instanz wie einen Entwicklungsserver in Ihrem lokalen LAN debuggen können. Wenn Sie dies tun, achten Sie natürlich darauf, dass der festgelegte Trace niemals auf Ihren Produktionsserver gelangt!

Kurz gesagt, Sie können immer noch das Gleiche tun wie die akzeptierte Antwort mit epdb ( import epdb; epdb.set_trace()), aber ich wollte die Serve-Funktionalität hervorheben, da ich sie so nützlich fand.

Ich habe gerade wdb gefunden ( http://www.rkblog.rk.edu.pl/w/p/debugging-python-code-browser-wdb-debugger/?goback=%2Egde_25827_member_255996401 ). Es hat eine ziemlich schöne Benutzeroberfläche / GUI mit allen Schnickschnack. Autor sagt dies über wdb -

"Es gibt IDEs wie PyCharm, die über eigene Debugger verfügen. Sie bieten ähnliche oder gleiche Funktionen ... Um sie jedoch verwenden zu können, müssen Sie diese spezifischen IDEs verwenden (und einige davon sind nicht kostenlos oder möglicherweise nicht für alle verfügbar Plattformen). Wählen Sie das richtige Werkzeug für Ihre Bedürfnisse. "

Ich dachte, ich würde es einfach weitergeben.

Auch ein sehr hilfreicher Artikel über Python-Debugger: https://zapier.com/engineering/debugging-python-boss/

Schließlich , wenn Sie möchten einen schönen graphischen Ausdruck Ihrer Call - Stack in Django, Kasse sehen: https://github.com/joerick/pyinstrument . Fügen Sie einfach pyinstrument.middleware.ProfilerMiddleware zu MIDDLEWARE_CLASSES hinzu und fügen Sie am Ende der Anforderungs-URL? Profile hinzu, um den Profiler zu aktivieren.

Kann pyinstrument auch über die Befehlszeile oder durch Importieren als Modul ausführen.

Fügen Sie in der entsprechenden Zeile des Python-Codes import pdb; pdb.set_trace()oder breakpoint() (form python3.7) hinzu und führen Sie es aus. Die Ausführung wird mit einer interaktiven Shell beendet. In der Shell können Sie Python-Code ausführen (dh Variablen drucken) oder Befehle verwenden wie:

• c Ausführung fortsetzen
• n Schritt zur nächsten Zeile innerhalb derselben Funktion
• s Schritt zur nächsten Zeile in dieser Funktion oder einer aufgerufenen Funktion
• q Beenden Sie den Debugger / die Ausführung

Siehe auch: https://poweruser.blog/setting-a-breakpoint-in-python-438e23fe6b28

Eine Ihrer besten Optionen zum Debuggen von Django-Code ist über wdb: https://github.com/Kozea/wdb

wdb funktioniert mit Python 2 (2.6, 2.7), Python 3 (3.2, 3.3, 3.4, 3.5) und Pypy. Noch besser ist es, ein Python 2-Programm mit einem Wdb-Server zu debuggen, der auf Python 3 ausgeführt wird, und umgekehrt, oder ein Programm zu debuggen, das auf einem Computer ausgeführt wird, wobei ein Debugging-Server auf einem anderen Computer innerhalb einer Webseite auf einem dritten Computer ausgeführt wird! Noch besser ist es jetzt, einen aktuell ausgeführten Python-Prozess / -Thread mithilfe der Code-Injektion über die Weboberfläche anzuhalten. (Dies erfordert die Aktivierung von gdb und ptrace.) Mit anderen Worten, es handelt sich um eine sehr erweiterte Version von pdb direkt in Ihrem Browser mit netten Funktionen.

Installieren Sie den Server, führen Sie ihn aus und fügen Sie in Ihrem Code Folgendes hinzu:

import wdb
wdb.set_trace()

Nach Angaben des Autors sind die Hauptunterschiede in Bezug auf pdb:

Für diejenigen, die das Projekt nicht kennen, ist wdb ein Python-Debugger wie pdb, aber mit einem raffinierten Web-Frontend und vielen zusätzlichen Funktionen, wie zum Beispiel:

• Hervorheben der Quellensyntax
• Visuelle Haltepunkte
• Interaktive Code-Vervollständigung mit jedi
• Anhaltende Haltepunkte
• Tiefe Objektinspektion mit Maus-Multithreading / Multiprocessing-Unterstützung
• Remote-Debugging
• Ausdrücke beobachten
• In der Debugger-Code-Edition
• Beliebte Webserver-Integration, um bei Fehlern zu brechen
• In Ausnahmefällen zum Beispiel während des Trace (nicht post mortem) im Gegensatz zum werkzeug debugger
• Einbruch aktuell laufender Programme durch Code-Injection (auf unterstützten Systemen)

Es hat eine großartige browserbasierte Benutzeroberfläche. Eine Freude zu benutzen! :) :)

Ich benutze PyCharm und verschiedene Debug-Tools. Haben Sie auch einen schönen Artikel über das einfache Einrichten dieser Dinge für Anfänger. Sie können hier beginnen. Es wird allgemein über das Debuggen von PDB und GUI bei Django-Projekten berichtet. Hoffe, jemand würde von ihnen profitieren.

Wenn Sie Aptana für die Django-Entwicklung verwenden, beachten Sie Folgendes: http://www.youtube.com/watch?v=qQh-UQFltJQ

Wenn nicht, sollten Sie es verwenden.

Die meisten Optionen werden bereits erwähnt. Um den Vorlagenkontext zu drucken, habe ich dafür eine einfache Bibliothek erstellt. Siehe https://github.com/edoburu/django-debugtools

Sie können damit den Vorlagenkontext ohne {% load %}Konstrukt drucken :

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

Es verwendet ein benutzerdefiniertes Druckformat, um die Variablen in einem <pre>Tag anzuzeigen .

Ich finde, Visual Studio Code eignet sich hervorragend zum Debuggen von Django-Apps. Die Standardparameter von python launch.json werden python manage.pymit dem angehängten Debugger ausgeführt, sodass Sie Haltepunkte festlegen und Ihren Code nach Belieben durchlaufen können.

Für diejenigen, die versehentlich pdb zu Live-Commits hinzufügen können, kann ich diese Erweiterung der # Koobz-Antwort vorschlagen:

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

Aus eigener Erfahrung gibt es zwei Möglichkeiten:

1. Verwenden Sie ipdb , ein erweiterter Debugger, der pdb mag.

   import ipdb;ipdb.set_trace()oder breakpoint() (aus Python3.7)

2. Verwenden Sie die Django-Shell. Verwenden Sie einfach den folgenden Befehl. Dies ist sehr hilfreich, wenn Sie eine neue Ansicht entwickeln.

   python manage.py shell

Ich empfehle dringend, PDB zu verwenden.

import pdb
pdb.set_trace()

Sie können alle Variablenwerte überprüfen, in die Funktion einsteigen und vieles mehr. https://docs.python.org/2/library/pdb.html

Ich verwende die Django-Debug-Toolbar https://github.com/django-debug-toolbar/django-debug-toolbar , um alle Arten von Anfragen, Antworten und Treffern für die Datenbank zu überprüfen

Wie in anderen Beiträgen hier erwähnt, ist das Festlegen von Haltepunkten in Ihrem Code und das Durchlaufen des Codes, um festzustellen, ob er sich wie erwartet verhält, eine gute Möglichkeit, etwas wie Django zu lernen, bis Sie ein gutes Gefühl dafür haben, wie sich alles verhält - und wie sich Ihr Code verhält macht.

Dazu würde ich die Verwendung von WingIde empfehlen. Genau wie andere erwähnte IDEs sind sie einfach und benutzerfreundlich, haben ein ansprechendes Layout und auch einfach zu setzende Haltepunkte. Bewerten / Ändern des Stapels usw. Perfekt, um zu visualisieren, was Ihr Code tut, wenn Sie ihn durchlaufen. Ich bin ein großer Fan davon.

Außerdem verwende ich PyCharm - es verfügt über eine hervorragende statische Code-Analyse und kann manchmal helfen, Probleme zu erkennen, bevor Sie feststellen, dass sie vorhanden sind.

Wie bereits erwähnt, ist die django-debug-Symbolleiste unerlässlich - https://github.com/django-debug-toolbar/django-debug-toolbar

Und obwohl dies kein explizites Debug- oder Analysetool ist, ist einer meiner Favoriten die SQL Printing Middleware, die von Django Snippets unter https://djangosnippets.org/snippets/290/ erhältlich ist.

Dadurch werden die von Ihrer Ansicht generierten SQL-Abfragen angezeigt. Dies gibt Ihnen einen guten Überblick darüber, was der ORM tut und ob Ihre Abfragen effizient sind oder Sie Ihren Code überarbeiten müssen (oder Caching hinzufügen müssen).

Ich finde es von unschätzbarem Wert, die Abfrageleistung beim Entwickeln und Debuggen meiner Anwendung im Auge zu behalten.

Nur ein weiterer Tipp: Ich habe es für meinen eigenen Gebrauch leicht modifiziert, um nur die Zusammenfassung und nicht die SQL-Anweisung anzuzeigen. Deshalb verwende ich es immer beim Entwickeln und Testen. Ich habe auch hinzugefügt, dass wenn die len (connection.queries) größer als ein vordefinierter Schwellenwert ist, eine zusätzliche Warnung angezeigt wird.

Wenn ich dann feststelle, dass etwas Schlimmes passiert (aus Sicht der Leistung oder der Anzahl der Abfragen), schalte ich die vollständige Anzeige der SQL-Anweisungen wieder ein, um genau zu sehen, was gerade passiert. Sehr praktisch, wenn Sie an einem großen Django-Projekt mit mehreren Entwicklern arbeiten.

benutze pdboder ipdb. Der Unterschied zwischen diesen beiden ist, dass ipdb die automatische Vervollständigung unterstützt.

für pdb

import pdb
pdb.set_trace()

für ipdb

import ipdb
ipdb.set_trace()

Zum Ausführen einer neuen nZeilentaste, zum Fortfahren der Treffer- cTaste. Überprüfen Sie weitere Optionen mithelp(pdb)

Ein zusätzlicher Vorschlag.

Sie können Nosetests und PDF zusammen nutzen, anstatt pdb.set_trace()Ihre Ansichten manuell einzufügen . Der Vorteil ist, dass Sie Fehlerbedingungen beim ersten Start beobachten können, möglicherweise im Code von Drittanbietern.

Hier ist ein Fehler für mich heute.

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 %}

Jetzt weiß ich, dass dies bedeutet, dass ich den Konstruktor für das Formular vermasselt habe, und ich habe sogar eine gute Vorstellung davon, welches Feld ein Problem ist. Aber kann ich pdb verwenden, um zu sehen, worüber sich knusprige Formen innerhalb einer Vorlage beschweren ?

Ja, ich kann. Mit Hilfe der --pdb Option auf nosetests:

tests$ nosetests test_urls_catalog.py --pdb

Sobald ich auf eine Ausnahme stoße (einschließlich solcher, die ordnungsgemäß behandelt wurden), stoppt pdb dort, wo es passiert, und ich kann mich umschauen.

  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)         

Nun ist es klar, dass mein Auswahlargument für den knusprigen Feldkonstruktor darin bestand, dass es sich um eine Liste innerhalb einer Liste handelte und nicht um eine Liste / ein Tupel von Tupeln.

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

Das Schöne ist, dass diese PDF-Datei im Code von crispy stattfindet, nicht in meinem, und ich musste sie nicht manuell einfügen.

Während der Entwicklung schnell hinzufügen

assert False, value

kann helfen, Probleme in Ansichten oder anderswo zu diagnostizieren, ohne dass ein Debugger verwendet werden muss.