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

Bardzo podoba mi się interaktywny debugger Werkzeug

. Jest to podobne do strony debugowania Django, z tą różnicą, że dostajesz interaktywną powłokę na każdym poziomie śledzenia. Jeśli używasz django-extensions, otrzymujesz polecenie zarządzania runserver_plus, które uruchamia serwer deweloperski i daje Debugger Werkzeug na wyjątkach.

Oczywiście, należy uruchamiać to tylko lokalnie, ponieważ daje to każdemu z przeglądarką prawa do wykonywania dowolnego kodu Pythona w kontekście serwer.

Mały szybki numerek dla znaczników szablonu:

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

Teraz wewnątrz szablonu możesz zrobić {{ template_var|pdb }} i wprowadzić sesję pdb (biorąc pod uwagę, że używasz lokalnego serwera devel), gdzie możesz sprawdzić element zgodnie z zawartością twojego serca.

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

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

Najważniejszy jest Django debug toolbar .

Następnie potrzebujesz dobrego logowania za pomocą obiektu Python logging. Możesz wysłać wyjście dziennika do pliku dziennika, ale łatwiejszą opcją jest wysłanie wyjścia dziennika do firepython . W tym celu należy użyć przeglądarki Firefox z rozszerzeniem firebug. Firepython zawiera wtyczkę firebug, która wyświetli wszelkie logowanie po stronie serwera w zakładce Firebug.

Sam Firebug jest również krytyczny dla debugowania strony Javascript każdej rozwijanej aplikacji. (Zakładając oczywiście, że masz jakiś kod JS).

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

Istnieje więcej przydatnych narzędzi, takich jak Spycharka do śledzenia wycieków pamięci (istnieją również inne dobre sugestie podane w odpowiedziach tutaj NA so do śledzenia pamięci).

Używam PyCharm (ten sam silnik pydev co eclipse). Naprawdę pomaga mi wizualnie być w stanie przejść przez mój kod i zobaczyć, co się dzieje.

Prawie wszystko zostało do tej pory wymienione, więc dodam tylko, że zamiast pdb.set_trace() można użyć ipdb.set_trace () , która używa ipythona i dlatego jest bardziej wydajna (autocomplete i inne gadżety). Wymaga to pakietu ipdb, więc wystarczy pip install ipdb

Przesunąłem django-pdb na PyPI . Jest to prosta aplikacja, która oznacza, że nie trzeba 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 swojego INSTALLED_APPS

Możesz teraz uruchomić: manage.py runserver --pdb, aby wł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 --pdb, aby włamać się do pdb przy niepowodzeniach testów / błędach...

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)

The project ' s hosted on GitHub , contributions oczywiście mile widziane.

Najprostszym sposobem debugowania Pythona-szczególnie dla programistów, którzy są przyzwyczajeni do 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 jest trafiony, możesz przeglądać / zmieniać zmienne tak łatwo, jak debugowanie programów C# / C++.
4. to wszystko:)

Jeśli chcesz debugować Django używając PTVS, musisz aby 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 zakładce Ustawienia projektu-Debug Ustaw "argumenty Skryptu" na "runserver --noreload". Kluczowym punktem jest tutaj "-- noreload". Jeśli go nie ustawisz, twoje punkty przerwania nie zostaną trafione.
Ciesz się tym.

Używam pyDev z Eclipse naprawdę dobrze, ustawiam punkty przerwania, wchodzę w kod, przeglądam wartości na dowolnych obiektach i zmiennych, wypróbowuję.

Używam PyCharm i jestem przy tym cały czas. Trochę mnie to kosztowało, ale muszę powiedzieć, że przewaga, którą z tego wyciągam, jest bezcenna. Próbowałem debugowania z konsoli i daję ludziom wiele uznania, którzy mogą to zrobić, ale dla mnie możliwość wizualnego debugowania mojej aplikacji jest świetna.

Muszę jednak powiedzieć, PyCharm wymaga dużo pamięci. Ale z drugiej strony, nic dobrego nie jest wolne w życiu. Właśnie przyszli z najnowszą wersją 3. Gra również bardzo dobrze z Django, Flask i Google AppEngine. Podsumowując, powiedziałbym, że jest to świetne poręczne narzędzie dla każdego dewelopera.

Jeśli nie używasz go jeszcze, polecam, aby uzyskać wersję próbną na 30 dni, aby spojrzeć na 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 komfortowo debugując tam moje aplikacje.

Z mojego punktu widzenia, moglibyśmy podzielić wspólne debugowanie kodu zadania na trzy różne wzorce użycia:

1. coś podniosło wyjątek: runserver_plus ' Werkzeug debugger na ratunek. Możliwość uruchamiania niestandardowego kodu na wszystkich poziomach śledzenia jest zabójcza. A jeśli jesteś całkowicie zablokowany, możesz utworzyć Gist do udostępnienia za pomocą jednego kliknięcia.
2. strona jest renderowana, ale wynik jest zły : znowu Werkzeug rządzi. Aby zrobić breakpoint w kodzie, po prostu wpisz assert False w miejscu, w którym chcesz się zatrzymać.
3. kod działa źle , ale szybkie spojrzenie nie pomaga. Najprawdopodobniej problem algorytmiczny. Westchnienie. Potem zwykle odpalam debugger konsoli PuDB: import pudb; pudb.set_trace(). Główną zaletą [i] pdb jest to, że PuDB (patrząc jak jesteś w latach 80-tych) sprawia, że ustawienie niestandardowych wyrażeń zegarka jest proste. A debugowanie kilku zagnieżdżonych pętli jest znacznie prostsze z GUI.

Czasami, gdy chcę się rozejrzeć w określonej metodzie i przywołanie pdb jest po prostu zbyt uciążliwe, dodam:

import IPython; IPython.embed()

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

Gorąco polecam epdb (Extended Python Debugger).

Https://bitbucket.org/dugan/epdb

Jedną z rzeczy, które uwielbiam w epdb do debugowania Django lub innych Webserverów Pythona, jest epdb.polecenie serve (). To ustawia ślad i służy do lokalnego portu, z którym można się połączyć. Typowy przypadek użycia:

Mam pogląd, przez który chcę przejść krok po kroku. Wstawię następujące w momencie, w którym chcę ustawić ślad.

import epdb; epdb.serve()

Gdy ten kod dostanie wykonywany, otwieram interpreter Pythona i podĹ ' Ä ... czam siÄ ™ do serwujÄ ... cej instancji. Mogę analizować wszystkie wartości i przejść 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 więcej, że możesz dowiedzieć się o pisaniu pomocy epdb w dowolnym momencie.

Jeśli chcesz obsługiwać lub łączyć się z wieloma instancjami epdb w tym samym czasie, możesz określić port, na którym chcesz nasłuchiwać (domyślnie jest to 8080). I. E.

import epdb; epdb.serve(4242)

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

Host domyślnie ustawia "localhost", jeśli nie jest określony. Wrzuciłem aby zademonstrować, w jaki sposób można tego użyć do debugowania czegoś innego niż lokalna instancja, np. serwera deweloperskiego w lokalnej sieci LAN. Oczywiście, jeśli to zrobisz, uważaj, aby set trace nigdy nie trafił na twój serwer produkcyjny!

Jako krótka notka, nadal możesz zrobić to samo, co zaakceptowana odpowiedź z epdb (import epdb; epdb.set_trace()), ale chciałem podkreślić funkcjonalność serwowania, ponieważ uznałem ją za tak przydatną.

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 ładny interfejs użytkownika / GUI ze wszystkimi dzwonkami i gwizdkami. Autor mówi tak o wdb-

" istnieją IDE takie jak PyCharm, które mają swoje własne debuggery. Oferują one podobny lub równy zestaw funkcji ... Aby jednak z nich korzystać, musisz użyć tych konkretnych IDE (a niektóre z nich są niewolne lub mogą nie być dostępne dla wszystkich perony). Wybierz odpowiednie narzędzie do swoich potrzeb."

Pomyślałem, że przekażę to dalej.

Również bardzo pomocny artykuł o debuggerach Pythona: https://zapier.com/engineering/debugging-python-boss/

Na koniec, jeśli chcesz zobaczyć ładny graficzny Wydruk twojego stosu połączeń w Django, checkout: https://github.com/joerick/pyinstrument. Wystarczy dodać pyinstrument.middleware.ProfilerMiddleware do MIDDLEWARE_CLASSES, a następnie dodać ?profil do koniec adresu URL żądania, aby aktywować profiler.

Może również uruchamiać pyinstrument z linii poleceń lub importując jako moduł.

Używam PyCharm i różnych narzędzi debugowania. Miej również ładny zestaw artykułów na temat łatwego konfigurowania tych rzeczy dla nowicjuszy. Możesz zacząć tutaj. mówi o debugowaniu PDB i GUI w ogóle z projektami Django. Mam nadzieję, że ktoś na nich skorzysta.

Jeśli używasz Aptany do rozwoju django, obejrzyj to: http://www.youtube.com/watch?v=qQh-UQFltJQ

Jeśli nie, rozważ użycie go.

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

Można go użyć do drukowania kontekstu szablonu Bez{% load %} konstrukcji:

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

Używa niestandardowego formatu pprint do wyświetlania zmiennych w znaczniku <pre>.

Uważam, że Visual Studio Code jest świetny do debugowania aplikacji Django. Standardowe uruchomienie Pythona.parametry json uruchamiają się python manage.py z dołączonym debuggerem, więc możesz ustawić punkty przerwania i przejść przez KOD, jak chcesz.

Dla tych, którzy mogą przypadkowo dodać pdb do Live commitów, mogę zaproponować rozszerzenie #Koobz odpowiedz:

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

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

Wdb współpracuje z Pythonem 2 (2.6, 2.7), Pythonem 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 Pythonie 3 i odwrotnie lub debugowanie programu działającego na komputerze z serwerem debugującym działającym na innym komputerze wewnątrz strony internetowej na trzecim komputerze! Jeszcze lepiej, teraz Można wstrzymać aktualnie uruchamianie procesu/wątku Pythona za pomocą wtrysku 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 przyjemnymi funkcjami.

Zainstaluj i uruchom serwer, a w kodzie dodaj:

import wdb
wdb.set_trace()

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

Dla tych, którzy nie znają projektu, wdb jest debuggerem Pythona, jak pdb, ale z eleganckim front-endem internetowym i wieloma o dodatkowych cechach, takich jak:

• podświetlanie składni Źródła
• wizualne punkty przerwania
• interaktywne uzupełnianie kodu za pomocą jedi
• trwałe punkty przerwania
• inspekcja głębokich obiektów przy użyciu obsługi wielowątkowości / Wieloprocesora myszy
• zdalne debugowanie
• Zegarek
• w edycji kodu debuggera
• popularna integracja serwerów WWW do złamania przy błędzie
• w wyjątku złamanie podczas śledzenia (nie po śmierci) w przeciwieństwie do debuggera werkzeug na przykład
• włamywanie się do aktualnie uruchomionych programów poprzez wstrzyknięcie kodu (na obsługiwanych systemach)

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

Dodaj import pdb; pdb.set_trace() do odpowiedniego wiersza w kodzie Pythona i wykonaj go. Wykonanie zakończy się interaktywną powłoką. W powłoce można wykonać kod Pythona (np. wydrukować zmienne) lub użyć poleceń takich jak:

• c Kontynuuj egzekucję
• n krok do następnego wiersza w ramach tej samej funkcji
• s krok do następnego wiersza w tej funkcji lub wywołanej funkcji
• q Zakończ debugger / wykonanie

Zobacz też: https://poweruser.blog / ustawianie-punktu-przerwania-w-Pythonie-438e23fe6b28

Sugeruję użycie PDB.

import pdb
pdb.set_trace()

Możesz sprawdzić wszystkie wartości zmiennych, wejść do funkcji i wiele więcej. https://docs.python.org/2/library/pdb.html

Do sprawdzania wszelkiego rodzaju zapytań, odpowiedzi i trafień do bazy danych.używam django-debug-toolbar https://github.com/django-debug-toolbar/django-debug-toolbar

Jak wspomniano w innych postach tutaj-ustawianie punktów przerwania w kodzie i przechodzenie przez kod, aby zobaczyć, czy zachowuje się tak, jak oczekiwałeś, jest świetnym sposobem na nauczenie się czegoś takiego jak Django, dopóki nie będziesz miał dobrego poczucia, jak to wszystko się zachowuje - i co robi twój kod.

W tym celu polecam użycie WingIde. Podobnie jak inne wymienione IDE ładny i łatwy w użyciu, ładny układ, a także łatwe do ustawienia punkty przerwania ocenić / zmodyfikować stos itp. Idealny do wizualizacji tego, co robi twój kod jak przez to przechodzisz. Jestem jej wielkim fanem.

Również używam PyCharm-ma doskonałą analizę kodu statycznego i może pomóc czasami dostrzec problemy, zanim zdasz sobie sprawę, że tam są.

Jak już wspomniano django-debug-toolbar jest niezbędny- https://github.com/django-debug-toolbar/django-debug-toolbar

I chociaż nie jest to wyraźnie narzędzie do debugowania lub analizy - jednym z moich ulubionych jest oprogramowanie pośredniczące do drukowania SQL dostępne z fragmentów Django na https://djangosnippets.org/snippets/290/

Spowoduje wyświetlenie zapytań SQL wygenerowanych przez twój widok. To da ci dobre poczucie tego, co robi ORM i czy Twoje zapytania są wydajne lub musisz przerobić kod (lub dodać buforowanie).

Uważam, że jest to bezcenne, aby mieć oko na wydajność zapytań podczas opracowywania i debugowania mojej aplikacji.

Jeszcze jedna wskazówka - zmodyfikowałem ją nieco na własny użytek, aby pokazać tylko podsumowanie, a nie Polecenie SQL.... Dlatego zawsze używam go podczas opracowywania i testowania. Dodałem również, że jeśli len (połączenie.zapytań) 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 perspektywy wydajności lub liczby zapytań), włączam pełne wyświetlanie poleceń SQL, aby zobaczyć dokładnie, co się dzieje. Bardzo przydatne, gdy pracujesz nad dużym projektem Django z wieloma programistami.

Dodatkowa sugestia.

Możesz wykorzystać nosetestyi pdb razem, zamiast ręcznie wstrzykiwać pdb.set_trace() do swoich poglądów. Zaletą jest to, że można zaobserwować warunki błędu podczas pierwszego uruchomienia, potencjalnie w kodzie strony trzeciej.

Tutaj jest 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 konstruktor dla formularza, a nawet mam dobre pojęcie, które pole jest problemem. Ale czy mogę użyć pdb, aby zobaczyć, co chrupiące formy jest w szablonie?

tests$ nosetests test_urls_catalog.py --pdb

Jak tylko uderzę w jakikolwiek wyjątek (w tym te obsługiwane z gracją), 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 mój argument wyboru do crispy field constructor był tak, jakby był listą wewnątrz listy, a nie listą / krotką krotek.

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

Najzabawniejsze jest to, że ten pdb ma miejsce w kodzie crispy ' ego, nie moim i nie musiałem go ręcznie wstawiać.

Użyj pdb lub ipdb. Różnica między nimi polega na tym, że ipdb obsługuje auto complete.

Dla pdb

import pdb
pdb.set_trace()

Dla ipdb

import ipdb
ipdb.set_trace()

Dla wykonania nowego klucza hit linii n, dla klawisza continue hit c. sprawdź więcej opcji używając help(pdb)

Podczas tworzenia, dodanie szybkiego

assert False, value

Może pomóc w diagnozowaniu problemów w widokach lub gdziekolwiek indziej, bez potrzeby używania debuggera.

Z własnego doświadczenia, są dwa sposoby:

1. Użyj ipdb , który jest ulepszonym debuggerem lubi pdb.

   import ipdb;ipdb.set_trace()

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

   python manage.py shell