Jak debugować w Django, dobry sposób? [Zamknięte]


587

Zacząłem więc uczyć się programowania w Pythonie, a później w Django . Za pierwszym razem ciężko było spojrzeć na trackbacki i właściwie dowiedzieć się, co zrobiłem źle i gdzie był błąd składniowy. Minęło już trochę czasu i po drodze, chyba mam rutynę w debugowaniu mojego kodu Django. Ponieważ zostało to zrobione na wczesnym etapie programowania, usiadłem i zastanawiałem się, czy to, co robię, jest nieskuteczne i czy można to zrobić szybciej. Zwykle udaje mi się znaleźć i poprawić błędy w moim kodzie, ale zastanawiam się, czy powinienem to robić szybciej?

Zwykle używam informacji debugowania, które Django podaje, gdy są włączone. Kiedy rzeczy kończą się tak, jak myślałem, często przerywam przepływ kodu z błędem składniowym i patrzę na zmienne w tym punkcie przepływu, aby dowiedzieć się, gdzie kod robi coś innego niż chciałem.

Ale czy można to poprawić? Czy są jakieś dobre narzędzia lub lepsze sposoby debugowania kodu Django?


2
lubię używać paska narzędzi django-debug-Tool, jego bardzo przydatny
Diego Vinícius

1
Lub użyj wbudowanego debugera programu Visual Studio Code w języku Python, jak wyjaśniono tutaj code.visualstudio.com/docs/python/tutorial-django
Nick T

Odpowiedzi:


536

Istnieje wiele sposobów, aby to zrobić, ale najprostszym jest po prostu użycie debugera w języku Python . Wystarczy dodać następujący wiersz do funkcji widoku Django:

import pdb; pdb.set_trace()

lub

breakpoint()  #from Python3.7

Jeśli spróbujesz załadować tę stronę w przeglądarce, przeglądarka się zawiesi i pojawi się monit o kontynuowanie debugowania rzeczywistego kodu wykonawczego.

Istnieją jednak inne opcje (nie polecam ich):

* return HttpResponse({variable to inspect})

* print {variable to inspect}

* raise Exception({variable to inspect})

Ale Python Debugger (pdb) jest wysoce zalecany dla wszystkich typów kodu Python. Jeśli jesteś już w pdb, powinieneś także zajrzeć na IPDB, który używa ipython do debugowania.

Niektóre bardziej przydatne rozszerzenia pdb są

pdb ++ , sugerowany przez Antash .

pudb , sugerowany przez PatDuJour .

Korzystanie z debugera Python w Django , sugerowanego przez Seafangs .


64
+1 za sugerowanie pdb. Warto jednak zauważyć, że tak naprawdę działa to tylko podczas używania serwera programistycznego na komputerze lokalnym, ponieważ monit pojawi się w konsoli.
Daniel Roseman,

12
Zobacz także django-pdb zgodnie z moją odpowiedzią poniżej. Daje ci manage.py runserver --pdbi manage.py test --pdbrozkazuje.
Tom Christie

4
@Daniel, zobacz rconsole, aby uzyskać konsolę w już działającej instancji Pythona.
Phob

12
Sprawdź ipythonrównież. Ipdb, który jest dostarczany ipython, zawiera funkcje uzupełniania tabulatorów, kolorową składnię i wiele więcej :-).
hobbes3

3
Uznałem twoją odpowiedź za przydatną, ale Django wisiał wiecznie na moich punktach przerwania, kiedy próbowałem debugować test. Więc szukałem i znalazłem informacyjny artykuł, który mi pomógł: v3.mike.tig.as/blog/2010/09/14/pdb
driftcatcher

228

Naprawdę lubię interaktywny debugger Werkzeug . Jest podobny do strony debugowania Django, z tym wyjątkiem, że otrzymujesz interaktywną powłokę na każdym poziomie śledzenia. Jeśli używasz rozszerzeń django , otrzymujesz runserver_pluspolecenie zarządzania, które uruchamia serwer programistyczny i daje ci debuger Werkzeug na wyjątkach.

Oczywiście powinieneś uruchamiać to tylko lokalnie, ponieważ daje każdemu z przeglądarki prawo do wykonania dowolnego kodu python w kontekście serwera.


2
Czy można używać uzupełniania tabulatorów w interaktywnej konsoli pokazanej w przeglądarce? „Tab” przenosi nas do następnej otwartej konsoli. Zastanawiałem się, czy istnieje kombinacja klawiszy, ale nie mogłem jej znaleźć.
Ariel

@Ariel debuger werkzeug nie ma ukończenia tabulacji.
Håken Lid

Jeśli debugujesz interfejsy API, możesz wypróbować program django-rundbg, który dodaje nieco zmian do debugera Werkzeug.
elpaquete,

To tylko dopython 3.3
Timo,

166

Trochę śmieci dla tagów szablonów:

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

Teraz w szablonie możesz zrobić {{ template_var|pdb }}sesję pdb i przejść do niej (pod warunkiem, że prowadzisz lokalny serwer deweloperski), gdzie możesz sprawdzić elementzawartość swojego serca.

To bardzo fajny sposób, aby zobaczyć, co się stało z twoim obiektem, gdy dotrze on do szablonu.


1
to jest świetne. Inną rzeczą, którą możesz zrobić, jeśli masz problemy z szablonami, jest przejście na jinja2 (ładowaną przez trumnę) - jest to rozszerzenie szablonów django, co jest moim zdaniem ulepszeniem. Integruje również szablony i dziedziczenie szablonów z ramkami traceback znacznie lepiej niż robi to w Django.
szybkie rozmnożenie

To jest urocze. Niestety, trudno jest znaleźć czysty sposób na zintegrowanie tego z bazą kodu, która odmawia jakiegokolwiek zatwierdzenia, w tym importu pdb.
Jon Kiparsky 30.01.16

83

Istnieje kilka narzędzi, które dobrze ze sobą współpracują i mogą ułatwić zadanie debugowania.

Najważniejszy jest pasek narzędzi debugowania Django .

Następnie potrzebujesz dobrego rejestrowania za pomocą funkcji rejestrowania w języku Python . Możesz wysłać dane wyjściowe dziennika do pliku dziennika, ale łatwiejszą opcją jest wysłanie danych wyjściowych dziennika do firepython . Aby tego użyć, musisz użyć przeglądarki Firefox z rozszerzeniem firebug . Firepython zawiera wtyczkę Firebug, która wyświetla dowolne logowanie po stronie serwera w zakładce Firebug.

Sam Firebug ma również kluczowe znaczenie dla debugowania strony JavaScript w każdej opracowywanej aplikacji. (Zakładając, że masz oczywiście kod JS).

Podobało mi się również django-viewtools do interaktywnego debugowania widoków za pomocą pdb, ale nie używam go zbyt często.

Istnieją bardziej użyteczne narzędzia, takie jak spycharka do śledzenia wycieków pamięci (w odpowiedzi tutaj na SO dotyczące śledzenia pamięci podano również inne dobre sugestie).


65

Używam PyCharm (tego samego silnika pydev co eclipse). Naprawdę pomaga mi wizualnie móc przejść przez mój kod i zobaczyć, co się dzieje.


2
najlepszą rzeczą jest to, że po prostu działa i jest całkowicie intuicyjny. Wystarczy kliknąć na lewo od linii i nacisnąć przycisk debugowania. Działa dobrze również dla kodu źródłowego Django, jeśli chcesz lepiej zrozumieć, jak działa kod wewnętrzny. Zajęło mi to trochę czasu, zanim to zauważyłem, ale możesz umieścić punkty przerwania w dowolnym kodzie w folderze Biblioteki zewnętrzne nawigatora plików.
Michael Bylstra

6
Warto wspomnieć, że PyCharm korzysta z debuggera PyDev pod maską, aby uzyskać kredyty.
Medeiros


44

Jak dotąd wspomniano prawie wszystko, więc dodam tylko, że zamiast pdb.set_trace()jednego można użyć ipdb.set_trace (), który używa iPython i dlatego jest bardziej wydajny (autouzupełnianie i inne gadżety). Wymaga to pakietu ipdb, więc wystarczypip install ipdb


2
Polecam pdb ++, który zapewnia bardzo przydatny tryb lepki.
Sandeep

34

Naciskałem django-pdbna PyPI . Jest to prosta aplikacja, która oznacza, że ​​nie musisz edytować kodu źródłowego za każdym razem, gdy chcesz włamać się do pdb.

Instalacja jest po prostu ...

  1. pip install django-pdb
  2. Dodaj 'django_pdb'do swojegoINSTALLED_APPS

Możesz teraz uruchomić: manage.py runserver --pdbwłamać się do pdb na początku każdego widoku ...

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)

I uruchom: manage.py test --pdbwłamać się do pdb przy błędach / błędach testu ...

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)

Projekt jest hostowany na GitHub , oczywiście mile widziane są prace.


3
Byłoby wspaniale, gdybyś mógł podać numer pliku / linii do złamania (nie tylko widok).
Anson MacKeracher

Do czego mógłbym zostawić w kodzie jak komentarze, które są obojętne w produkcji. Być może jest to zły paradim, ale byłoby dobrze, gdyby skutecznie rozebrać i zastosować przerwy nie chcąc.
Gliceryna

Zainstalowałem to niedawno, ale dopiero dzisiaj wymyśliłem, aby skonfigurować „POST_MORTEM = True” w moich ustawieniach programisty, jak udokumentowano w django-pdb Toma. Teraz mogę po prostu pływać, a gdy coś pójdzie nie tak, spadam prosto na miejsce problemu. Dzięki Tom!
Joseph Sheedy

21

Najłatwiejszym sposobem debugowania Pythona - szczególnie dla programistów używanych w Visual Studio - jest użycie PTVS (Python Tools for Visual Studio). Kroki są proste:

  1. Pobierz i zainstaluj go z http://pytools.codeplex.com/
  2. Ustaw punkty przerwania i naciśnij F5.
  3. Twój punkt przerwania został trafiony, możesz przeglądać / zmieniać zmienne tak łatwo, jak debugowanie programów C # / C ++.
  4. To wszystko :)

Jeśli chcesz debugować Django za pomocą PTVS, musisz wykonać następujące czynności:

  1. W Ustawieniach projektu - zakładka Ogólne, ustaw „Plik startowy” na „manage.py”, punkt wejścia programu Django.
  2. W Ustawieniach projektu - zakładka Debugowanie, ustaw „Argumenty skryptów” na „runserver --noreload”. Kluczowym punktem jest tutaj „--noreload”. Jeśli go nie ustawisz, punkty przerwania nie zostaną trafione.
  3. Ciesz się

1
Dzięki, działało świetnie. - Noreload był tym, czego potrzebowaliśmy
Tom Gruner

Czy jest funkcja do debugowania na zdalnym serwerze - podobna do Eclipse PyDev, której obecnie używam?
Daniel Sokołowski,

Mam z tym problemy. Śledziłem twoje kroki, ale nadal nie działa. Zatrzymuje się tylko w punktach przerwania plików * .py, a nie w plikach * .html.
blfuentes

16

Używam pyDev z Eclipse naprawdę dobrze, ustawiam punkty przerwania, wkraczam do kodu, wyświetlam wartości dowolnych obiektów i zmiennych, wypróbowuję.


Musisz uruchomić serwer deweloperów przez eclipse (dla łatwego debugowania). PyDev twierdzi, że ma zdalne debugowanie, ale nigdy go nie użyłem, tak naprawdę nie mogę mówić o jakości programowania. Szczegóły: pydev.org/manual_adv_remote_debugger.html
synthesizerpatel

2
Zdalny debugger PyDev działa całkiem nieźle z serwerem programistów Django. Tylko upewnij się, że masz opcję „Gdy plik zostanie zmieniony, automatycznie przeładuj moduł?” opcja „wyłączona” w ustawieniach uruchamiania / debugowania PyDev. W przeciwnym razie serwer programistów i pydev spróbują ponownie załadować kod podczas debugowania, co powoduje, że oba są bardzo zdezorientowane.
coredumperror

12

Używam PyCharm i stoję przy tym przez cały czas. Trochę mnie to kosztowało, ale muszę powiedzieć, że korzyść, którą z tego czerpię, jest bezcenna. Próbowałem debugować z konsoli i daję ludziom dużo uznania, kto może to zrobić, ale dla mnie możliwość wizualnego debugowania moich aplikacji jest świetna.

Muszę jednak powiedzieć, że PyCharm zajmuje dużo pamięci. Ale z drugiej strony nic dobrego nie jest w życiu wolne. Właśnie przyszedł z ich najnowszą wersją 3. To także działa bardzo dobrze z Django, Flask i Google AppEngine. Podsumowując, powiedziałbym, że to świetne przydatne narzędzie dla każdego programisty.

Jeśli jeszcze go nie używasz, polecam pobrać wersję próbną na 30 dni, aby sprawdzić moc PyCharm. Jestem pewien, że dostępne są również inne narzędzia, takie jak Aptana. Ale chyba też podoba mi się wygląd PyCharm. Czuję się bardzo dobrze debugując tam moje aplikacje.


To może być pierwsze IDE, jakie kiedykolwiek kupiłem. Debugowanie projektu na maszynie wirtualnej brzmi jak magia, za którą warto zapłacić.
Rob Grant,

10

Czasami, kiedy chcę badać konkretną metodę i przywoływanie pdb jest po prostu zbyt kłopotliwe, dodam:

import IPython; IPython.embed()

IPython.embed() uruchamia powłokę IPython, która ma dostęp do zmiennych lokalnych od miejsca, w którym ją wywołujesz.


Przyzwyczaiłem się teraz robić to na górze pliku, from IPython import embeda potem, gdy chcę szybko dodać punkt przerwania w kodzie, piszę embed(). Oszczędza czas. Aby uniknąć utknięcia w pętli na zawsze, robię toembed();exit();
Mayank Jaiswal

@MayankJaiswal: Miałem mapowanie klawiszy w Vimie, aby wstawić ten fragment (i podobne fragmenty dla pudbi debugger;w JavaScript) do pliku, który edytuję. Po zakończeniu po prostu dd(usuwam całą linię), aby usunąć punkt przerwania. Pozwala to uniknąć ryzyka wprowadzenia linii importu debuggera do kontroli wersji lub konieczności wcześniejszego ustawienia importu na początku pliku.
Lie Ryan

10

Z mojej perspektywy możemy podzielić typowe zadania debugowania kodu na trzy różne wzorce użytkowania:

  1. Coś podniosło wyjątek : debugger Werkzeug runserver_plus na ratunek. Możliwość uruchamiania niestandardowego kodu na wszystkich poziomach śledzenia jest zabójcza. A jeśli całkowicie utkniesz, możesz utworzyć listę zadań, którą możesz udostępnić jednym kliknięciem.
  2. Strona jest renderowana, ale wynik jest nieprawidłowy : ponownie Werkzeug się kołysze. Aby utworzyć punkt przerwania w kodzie, po prostu wpisz assert Falsemiejsce, w którym chcesz się zatrzymać.
  3. Kod działa źle , ale szybki przegląd nie pomaga. Najprawdopodobniej problem algorytmiczny. Westchnienie. Potem zwykle odpalić konsolę debuggera PuDB : import pudb; pudb.set_trace(). Główną zaletą w stosunku do [i] pdb jest to, że PuDB (patrząc jak jesteś w latach 80-tych) sprawia, że ​​ustawianie niestandardowych wyrażeń zegarka jest dziecinnie proste. A debugowanie wiązki zagnieżdżonych pętli jest o wiele prostsze dzięki GUI.

Ach, tak, nieszczęścia szablonów. Najczęstszym (dla mnie i moich kolegów) problemem jest niewłaściwy kontekst: albo nie masz zmiennej, albo twoja zmienna nie ma żadnego atrybutu. Jeśli używasz paska narzędzi do debugowania , po prostu sprawdź kontekst w sekcji „Szablony” lub, jeśli to nie wystarczy, ustaw przerwę w kodzie widoków zaraz po zapełnieniu kontekstu.

Tak to idzie.


pisz mniej używając justimport pudb;pu.db
Sławomir Lenart

6

Bardzo polecam epdb (Extended Python Debugger).

https://bitbucket.org/dugan/epdb

Jedną z rzeczy, które uwielbiam w epdb do debugowania Django lub innych serwerów Python jest komenda epdb.serve (). Ustawia to śledzenie i podaje je na lokalnym porcie, z którym można się połączyć. Typowy przypadek użycia:

Mam pogląd, że chcę przejść krok po kroku. Wstawię następujące w miejscu, w którym chcę ustawić śledzenie.

import epdb; epdb.serve()

Po uruchomieniu tego kodu otwieram interpreter języka Python i łączę się z instancją obsługującą. Mogę analizować wszystkie wartości i przechodzić przez kod za pomocą standardowych poleceń pdb, takich jak n, s itp.

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

I mnóstwo innych informacji na temat pisania pomocy epdb w dowolnym momencie.

Jeśli chcesz obsługiwać lub łączyć się z wieloma instancjami epdb jednocześnie, możesz określić port, na którym chcesz nasłuchiwać (domyślnie jest to 8080). To znaczy

import epdb; epdb.serve(4242)

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

host domyślnie ustawiony na „localhost”, jeśli nie został określony. Wrzuciłem to tutaj, aby zademonstrować, jak możesz to wykorzystać do debugowania czegoś innego niż lokalna instancja, na przykład serwer programistyczny w lokalnej sieci LAN. Oczywiście, jeśli to zrobisz, uważaj, aby zestaw śledzenia nigdy nie dotarł do twojego serwera produkcyjnego!

W skrócie, możesz nadal robić to samo co zaakceptowana odpowiedź za pomocą epdb ( import epdb; epdb.set_trace()), ale chciałem podkreślić funkcjonalność serwowania, ponieważ uważam ją za bardzo przydatną.


epdb nie jest aktualizowany od 2011 roku. Czy masz czasem problemy z używaniem go w nowszych wersjach Django i / lub Pythona?
Seperman

Nigdy nie miałem problemów z używaniem go w Pythonie 2 (w szczególności 2.4-2.7). Właściwie użyłem go kilka dni temu. Nigdy nie próbowałem z Python 3.
Jacinda

1
Używam django 1.8 na Pythonie 2.7 i nie mogę uzyskać dostępu do epdb.connect do rozmowy z epdb.serve. Właśnie dostałem przerwę.
David Watson,

6

Właśnie znalazłem wdb ( http://www.rkblog.rk.edu.pl/w/p/debugging-python-code-browser-wdb-debugger/?goback=%2Egde_25827_member_255996401 ). Ma całkiem niezły interfejs użytkownika / GUI ze wszystkimi dzwonkami i gwizdkami. Autor mówi to o wdb -

„Istnieją IDE, takie jak PyCharm, które mają własne debuggery. Oferują podobny lub równy zestaw funkcji ... Jednak aby z nich skorzystać, musisz użyć tych konkretnych IDE (a niektóre z nich są niewolne lub mogą nie być dostępne dla wszystkich platformy). Wybierz narzędzie odpowiednie do swoich potrzeb ”.

Myślałem, że po prostu to przekażę.

Również bardzo pomocny artykuł o debuggerach w języku Python: https://zapier.com/engineering/debugging-python-boss/

Na koniec , jeśli chcesz zobaczyć ładny graficzny wydruk stosu wywołań w Django, sprawdź: https://github.com/joerick/pyinstrument . Wystarczy dodać pyinstrument.middleware.ProfilerMiddleware do MIDDLEWARE_CLASSES, a następnie dodać profil? Na końcu adresu URL żądania, aby aktywować profilowanie.

Można również uruchomić narzędzie Pyinstrument z wiersza polecenia lub importując jako moduł.


PyCharm po prostu używa PyDev, jak sądzę, a nie własnego.
Rob Grant,

6

Dodaj import pdb; pdb.set_trace()lubbreakpoint() (formularz python3.7) w odpowiednim wierszu kodu Python i uruchom go. Wykonanie zakończy się za pomocą interaktywnej powłoki. W powłoce możesz wykonać kod Pythona (tj. Wypisać zmienne) lub użyć poleceń takich jak:

  • c kontynuować wykonywanie
  • n przejdź do następnego wiersza w ramach tej samej funkcji
  • s przejdź do następnego wiersza tej funkcji lub funkcji wywoływanej
  • q zamknij debugger / wykonanie

Zobacz także: https://poweruser.blog/setting-a-breakpoint-in-python-438e23fe6b28


5

Jedną z najlepszych opcji debugowania kodu Django jest wdb: https://github.com/Kozea/wdb

wdb działa z python 2 (2.6, 2.7), python 3 (3.2, 3.3, 3.4, 3.5) i pypy. Co więcej, możliwe jest debugowanie programu python 2 z serwerem wdb działającym na python 3 i odwrotnie lub debugowanie programu działającego na komputerze z serwerem debugującym uruchomionym na innym komputerze na stronie internetowej na trzecim komputerze! Nawet lepiej, można teraz wstrzymać aktualnie działający proces / wątek Pythona za pomocą wstrzyknięcia kodu z interfejsu WWW. (Wymaga to włączenia gdb i ptrace) Innymi słowy, jest to bardzo ulepszona wersja pdb bezpośrednio w przeglądarce z ładnymi funkcjami.

Zainstaluj i uruchom serwer, a w kodzie dodaj:

import wdb
wdb.set_trace()

Według autora główne różnice w odniesieniu do pdb:

Dla tych, którzy nie znają projektu, wdb jest debuggerem Pythona, takim jak pdb, ale z eleganckim interfejsem sieciowym i wieloma dodatkowymi funkcjami, takimi jak:

  • Podświetlanie składni źródłowej
  • Wizualne punkty przerwania
  • Interaktywne uzupełnianie kodu za pomocą jedi
  • Trwałe punkty przerwania
  • Kontrola obiektów głębokich za pomocą myszy Wielowątkowość / Obsługa wielu procesów
  • Zdalne debugowanie
  • Oglądaj wyrażenia
  • W edycji kodu debuggera
  • Popularna integracja serwerów WWW w celu złamania błędu
  • Wyjątkiem jest łamanie podczas śledzenia (nie pośmiertne), na przykład w przeciwieństwie do debuggera werkzeug
  • Włamanie się do aktualnie działających programów poprzez wstrzyknięcie kodu (w obsługiwanych systemach)

Ma świetny interfejs użytkownika oparty na przeglądarce. Radość z użytkowania! :)


Jaka jest różnica w przypadku pdb?
Dunatotatos

4

Używam PyCharm i różnych narzędzi do debugowania. Przygotuj też fajny zestaw artykułów na temat łatwego konfigurowania tych rzeczy dla nowicjuszy. Możesz zacząć tutaj. Mówi ogólnie o debugowaniu PDB i GUI w projektach Django. Mam nadzieję, że ktoś z nich skorzysta.



2

Większość opcji jest już wspomniana. Aby wydrukować kontekst szablonu, stworzyłem do tego prostą bibliotekę. Zobacz https://github.com/edoburu/django-debugtools

Możesz go użyć do wydrukowania kontekstu szablonu bez żadnej {% load %}konstrukcji:

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

Wykorzystuje dostosowany format pprint do wyświetlania zmiennych w <pre>znaczniku.


2

Uważam, że Visual Studio Code jest świetny do debugowania aplikacji Django. Standardowe parametry launch.json w Pythonie działają python manage.pyz dołączonym debuggerem, dzięki czemu można ustawić punkty przerwania i krok po kroku, jak chcesz.


2

Dla tych, którzy mogą przypadkowo dodać pdb do zatwierdzeń na żywo, mogę zasugerować to rozszerzenie odpowiedzi #Koobz:

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

2

Z własnego doświadczenia wynika, że ​​są dwa sposoby:

  1. użyj ipdb , który jest ulepszonym debuggerem, takim jak pdb.

    import ipdb;ipdb.set_trace()lub breakpoint() (z python3.7)

  2. użyj powłoki django, po prostu użyj poniższego polecenia. Jest to bardzo pomocne podczas opracowywania nowego widoku.

    python manage.py shell



1

Jak wspomniano w innych postach tutaj - ustawianie punktów przerwania w kodzie i przechodzenie przez kod, aby sprawdzić, czy zachowuje się on zgodnie z oczekiwaniami, to świetny sposób na nauczenie się czegoś takiego jak Django, dopóki nie zorientujesz się, jak to wszystko się zachowuje - i jaki jest twój kod to robi.

W tym celu polecam użycie WingIde. Podobnie jak inne wspomniane IDE ładne i łatwe w użyciu, ładny układ, a także łatwe do ustawienia punkty przerwania oceniają / modyfikują stos itp. Idealne do wizualizacji tego, co robi Twój kod, gdy go przechodzisz. Jestem wielkim fanem tego.

Używam również PyCharm - ma doskonałą analizę kodu statycznego i może czasem pomóc wykryć problemy, zanim zdasz sobie sprawę, że one istnieją.

Jak już wspomniano, pasek narzędzi debugowania django jest niezbędny - https://github.com/django-debug-toolbar/django-debug-toolbar

I choć nie jest to jawnie narzędzie do debugowania lub analizy - jednym z moich ulubionych jest oprogramowanie pośredniczące do drukowania SQL dostępne w Django Snippets pod adresem https://djangosnippets.org/snippets/290/

Spowoduje to wyświetlenie zapytań SQL wygenerowanych przez Twój widok. To da ci dobre wyobrażenie o tym, co robi ORM i czy twoje zapytania są wydajne lub musisz przerobić kod (lub dodać buforowanie).

Uważam, że nieocenione jest monitorowanie wydajności zapytań podczas opracowywania i debugowania aplikacji.

Jeszcze jedna wskazówka - zmodyfikowałem ją nieznacznie na własny użytek, aby wyświetlała tylko podsumowanie, a nie instrukcję SQL ... Więc zawsze używam jej podczas programowania i testowania. Dodałem również, że jeśli len (connection.queries) jest większy niż wstępnie zdefiniowany próg, wyświetla dodatkowe ostrzeżenie.

Następnie, jeśli zauważę, że dzieje się coś złego (z punktu widzenia wydajności lub liczby zapytań), włączam ponownie pełne wyświetlanie instrukcji SQL, aby zobaczyć dokładnie, co się dzieje. Bardzo przydatny, gdy pracujesz nad dużym projektem Django z wieloma programistami.


1

użyj pdblubipdb . Różnica między tymi dwoma jest ipdb obsługuje automatyczne uzupełnianie.

dla pdb

import pdb
pdb.set_trace()

dla ipdb

import ipdb
ipdb.set_trace()

Do wykonania nklawisza nowej linii, klawisz kontynuacji linii c. zaznacz więcej opcji za pomocąhelp(pdb)


0

Dodatkowa sugestia.

Możesz wykorzystać testy nosa i pdb razem, zamiast wstrzykiwaniapdb.set_trace() ręcznie swoje widoki. Zaletą jest to, że można zaobserwować warunki błędu przy pierwszym uruchomieniu, potencjalnie w kodzie innej firmy.

Oto błąd dla mnie dzisiaj.

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

Teraz wiem, że to oznacza, że ​​wygłupiłem konstruktora formularza i nawet mam dobre pojęcie, które pole jest problemem. Ale czy mogę użyć pdb, aby zobaczyć, na co chrupiące formularze narzekają, w szablonie ?

Tak, mogę. Korzystanie z --pdb opcję nosetests:

tests$ nosetests test_urls_catalog.py --pdb

Jak tylko trafię na jakiś wyjątek (w tym te obsługiwane z wdziękiem), pdb zatrzymuje się tam, gdzie to się dzieje, i mogę się rozejrzeć.

  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)         

Teraz jest jasne, że moim argumentem wyboru do konstruktora chrupiącego pola była lista, która była listą, a nie lista / krotka krotek.

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

Fajne jest to, że ten pdb odbywa się w kodzie chrupiącego, a nie mojego i nie musiałem go wstawiać ręcznie.


0

Podczas programowania dodawanie szybkie

assert False, value

może pomóc zdiagnozować problemy w widokach lub gdziekolwiek indziej, bez potrzeby korzystania z debuggera.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.