Djangoでデバッグする方法、良い方法？[閉まっている]

それで、私はPythonとその後のDjangoでコードを学ぶことを始めました。初めてトレースバックを見るのは大変で、実際に私が間違ったことと構文エラーの場所を突き止めました。時が経ち、途中でDjangoコードをデバッグするルーチンができたと思います。これは私のコーディング経験の早い段階で行われたため、私は座って、これを行う方法は効果がなく、より高速に実行できるかどうか疑問に思いました。私は通常、コード内のバグを見つけて修正することができますが、もっと速く実行する必要があるのでしょうか。

私は通常、Djangoが有効にしたときに提供するデバッグ情報を使用します。思ったとおりに結果が得られたら、構文エラーでコードフローを大幅に中断し、フローのその時点で変数を調べて、コードが希望とは異なる何かを行う場所を見つけ出します。

しかし、これを改善できますか？Djangoコードをデバッグするための優れたツールやより良い方法はありますか？

これを行う方法はたくさんありますが、最も簡単なのは、単にPythonデバッガを使用することです。Djangoビュー関数に次の行を追加するだけです。

import pdb; pdb.set_trace()

または

breakpoint()  #from Python3.7

ブラウザでそのページをロードしようとすると、ブラウザがハングし、実際に実行されているコードのデバッグを続行するように求めるプロンプトが表示されます。

ただし、他のオプションもあります（お勧めしません）。

* return HttpResponse({variable to inspect})

* print {variable to inspect}

* raise Exception({variable to inspect})

ただし、Pythonデバッガ（pdb）は、すべてのタイプのPythonコードに強く推奨されます。すでにpdb を使用している場合は、デバッグにipythonを使用するIPDBも確認してください。

pdbのいくつかのより便利な拡張は

Antashによって提案された pdb ++。

PatDuJourによって提案された pudb。

Seafangsによって提案されたDjangoのPythonデバッガーの使用。

Werkzeugの対話型デバッガが本当に好きです。これは、トレースバックのすべてのレベルでインタラクティブなシェルを取得することを除いて、Djangoのデバッグページに似ています。django-extensionsを使用するrunserver_plusと、開発サーバーを起動し、例外時にWerkzeugのデバッガーを提供する管理コマンドを取得します。

もちろん、サーバーのコンテキストで任意のpythonコードを実行する権限をブラウザーを持つすべてのユーザーに与えるため、これはローカルでのみ実行する必要があります。

テンプレートタグのちょっとしたクイック：

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

これで、テンプレート内で{{ template_var|pdb }}pdbセッションを実行して入力できます（ローカル開発サーバーを実行している場合）。ここで、element内容を確認できます。

これは、オブジェクトがテンプレートに到達したときにオブジェクトに何が起こったかを確認するのに非常に便利な方法です。

うまく連携してデバッグ作業を容易にするツールがいくつかあります。

最も重要なのは、Djangoデバッグツールバーです。

次に、Python ロギング機能を使用した適切なロギングが必要です。ログ出力をログファイルに送信できますが、より簡単なオプションはログ出力をfirepythonに送信することです。これを使用するには、Firebug拡張機能を備えたFirefoxブラウザーを使用する必要があります。Firepythonには、Firebugタブにサーバー側のログを表示するfirebugプラグインが含まれています。

Firebug自体も、開発するアプリのJavascript側をデバッグするために重要です。（もちろん、JSコードがあると仮定します）。

また、pdbを使用してインタラクティブにビューをデバッグするためのdjango-viewtoolsも気に入りましたが、あまり使用していません。

メモリーリークを追跡するためのドーザーのようなより便利なツールがあります（メモリー追跡のためのSOの回答で提供されている他の良い提案もあります）。

私はPyCharm（Eclipseと同じpydevエンジン）を使用しています。コードを視覚的にステップスルーして何が起こっているかを確認できるように本当に助けてくれます。

これまでにほとんどすべてのことを述べてきたので、iPythonを使用してより強力な（オートコンプリートやその他の機能）ipdb.set_trace（）を使用pdb.set_trace()できる代わりに、それだけを追加します。これにはipdbパッケージが必要なので、必要なのはpip install ipdb

PyPIにプッシュdjango-pdbしました。これはシンプルなアプリなので、pdbに侵入するたびにソースコードを編集する必要はありません。

インストールは...

1. pip install django-pdb
2. 追加'django_pdb'あなたへINSTALLED_APPS

これで実行できます：manage.py runserver --pdbすべてのビューの開始時にpdbに侵入します...

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)

そして実行：manage.py test --pdbテストの失敗/エラーでpdbに侵入する...

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)

プロジェクトはGitHubでホストされています。寄稿はもちろん歓迎します。

Pythonをデバッグする最も簡単な方法-特にVisual Studioに慣れているプログラマーにとって-は、PTVS（Python Tools for Visual Studio）を使用することです。手順は簡単です：

1. http://pytools.codeplex.com/からダウンロードしてインストールします
2. ブレークポイントを設定し、F5キーを押します。
3. ブレークポイントに到達すると、C＃/ C ++プログラムのデバッグと同じくらい簡単に変数を表示/変更できます。
4. それで全部です ：）

PTVSを使用してDjangoをデバッグする場合は、以下を実行する必要があります。

1. [プロジェクトの設定-全般]タブで、[スタートアップファイル]をDjangoプログラムのエントリポイントである "manage.py"に設定します。
2. [プロジェクトの設定-デバッグ]タブで、[スクリプトの引数]を[runserver --noreload]に設定します。ここで重要なのは「--noreload」です。これを設定しないと、ブレークポイントにヒットしません。
3. 楽しめ。

私はEclipseでpyDevを使用していて、ブレークポイントを設定し、コードにステップインし、オブジェクトと変数の値を表示して、試してみました。

私はPyCharmを使用し、それをずっと待機しています。それは私に少し費用がかかりますが、私がそれから得る利点は貴重であると言わざるを得ません。コンソールからデバッグを試してみましたが、それを実行できる人に多くの信用を与えていますが、アプリケーションを視覚的にデバッグできることは素晴らしいことです。

ただし、PyCharmは大量のメモリを消費します。しかし、繰り返しになりますが、人生において無料で良いものはありません。彼らはちょうど彼らの最新バージョン3が付属しています。また、Django、Flask、Google AppEngineで非常にうまく機能します。つまり、全体として、どの開発者にとっても便利なツールだと思います。

まだ使用していない場合は、30日間の試用版を入手して、PyCharmの機能を確認することをお勧めします。Aptanaなどの他のツールも利用できると思います。しかし、私はPyCharmの見た目も好きだと思います。そこでのアプリのデバッグはとても快適です。

特定の方法を試してみて、pdbを呼び出すのが面倒すぎる場合は、次のように追加します。

import IPython; IPython.embed()

IPython.embed() 呼び出す場所からローカル変数にアクセスできるIPythonシェルを起動します。

私の観点からは、一般的なコードのデバッグタスクを3つの異なる使用パターンに分解できます。

1. 何かが例外を発生させました：runserver_plus 'Werkzeugデバッガーが助けになりました。すべてのトレースレベルでカスタムコードを実行する機能は、キラーです。そして、完全に行き詰まっている場合は、クリックするだけで共有するGistを作成できます。
2. ページはレンダリングされますが、結果は間違っています。コードでブレークポイントを作成するには、assert False停止したい場所に入力するだけです。
3. コードは正しく動作しませんが、クイックルックは役に立ちません。おそらくアルゴリズムの問​​題です。はぁ。その後、私は通常、デバッガコンソールを起動PuDB：import pudb; pudb.set_trace()。[i] pdbに対する主な利点は、PuDB（80年代のように見ながら）がカスタムウォッチ式の設定を簡単にすることです。入れ子になったループの束のデバッグは、GUIを使用するとはるかに簡単になります。

ああ、はい、テンプレートの問題です。（私と私の同僚にとって）最も一般的な問題は、コンテキストが間違っていることです。変数がないか、変数に属性がありません。デバッグツールバーを使用している場合は、[テンプレート]セクションでコンテキストを調べるか、不十分な場合は、コンテキストがいっぱいになった直後にビューのコードにブレークを設定します。

だからそうなるのです。

epdb（拡張Pythonデバッガー）を強くお勧めします。

https://bitbucket.org/dugan/epdb

Djangoや他のPythonウェブサーバーをデバッグするためにepdbについて気に入っている点の1つは、epdb.serve（）コマンドです。これにより、トレースが設定され、接続可能なローカルポートで提供されます。典型的なユースケース：

順を追って説明したいのですが。トレースを設定したい箇所に以下を挿入します。

import epdb; epdb.serve()

このコードが実行されたら、Pythonインタープリターを開いて、サービングインスタンスに接続します。すべての値を分析し、n、sなどの標準のpdbコマンドを使用してコードをステップ実行できます。

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

さらに、epdbのヘルプの入力についていつでも学ぶことができる多くのことを学びます。

複数のepdbインスタンスを同時に提供または接続する場合は、リッスンするポートを指定できます（デフォルトは8080）。すなわち

import epdb; epdb.serve(4242)

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

指定しない場合、ホストはデフォルトで「localhost」になります。これをここに入れて、これを使用して、ローカルLAN上の開発サーバーなど、ローカルインスタンス以外のものをデバッグする方法を示します。明らかに、これを行う場合は、set traceが運用サーバーに到達しないように注意してください。

簡単なメモとして、epdb（import epdb; epdb.set_trace()）を使用しても、受け入れられた回答と同じことを行うことができますが、役立つので、サーブ機能を強調したいと思います。

wdbを見つけました（http://www.rkblog.rk.edu.pl/w/p/debugging-python-code-browser-wdb-debugger/?goback=%2Egde_25827_member_255996401）。それはすべてのベルとホイッスルを備えたかなり素晴らしいユーザーインターフェイス/ GUIを持っています。著者はwdbについてこれを言います-

「独自のデバッガーを備えたPyCharmのようなIDEがあります。それらは類似または同等の機能セットを提供します...ただし、それらを使用するには、それらの特定のIDEを使用する必要があります（一部のIDEはフリーではないか、すべてに利用できない場合がありますプラットフォーム）。ニーズに適したツールを選択してください。」

私はそれを渡すだけだと思った。

また、Pythonデバッガーに関する非常に役立つ記事： https : //zapier.com/engineering/debugging-python-boss/

最後に、Djangoでコールスタックをグラフィカルに表示したい場合は、https：//github.com/joerick/pyinstrumentをチェックアウトして ください。pyinstrument.middleware.ProfilerMiddlewareをMIDDLEWARE_CLASSESに追加してから、リクエストURLの最後に？profileを追加して、プロファイラーをアクティブ化します。

コマンドラインから、またはモジュールとしてインポートすることにより、pyinstrumentを実行することもできます。

Pythonコードの対応する行にimport pdb; pdb.set_trace()or breakpoint() （フォームpython3.7）を追加して実行します。実行は対話型シェルで停止します。シェルでは、Pythonコード（つまり、印刷変数）を実行するか、次のようなコマンドを使用できます。

• c 実行を続ける
• n 同じ関数内の次の行にステップ
• s この関数または呼び出された関数の次の行にステップ
• q デバッガー/実行を終了する

こちらもご覧ください：https : //poweruser.blog/setting-a-breakpoint-in-python-438e23fe6b28

Djangoコードをデバッグするための最良のオプションの1つは、wdbを使用することです：https : //github.com/Kozea/wdb

wdbは、python 2（2.6、2.7）、python 3（3.2、3.3、3.4、3.5）、およびpypyで動作します。さらに良いことに、python 3で実行されているwdbサーバーを使用してpython 2プログラムをデバッグしたり、その逆を行ったり、別のコンピューターで実行されているコンピューターで実行されているプログラムを別のコンピューターのWebページ内の別のコンピューターでデバッグしたりできます。さらに良いことに、Webインターフェイスからのコードインジェクションを使用して、現在実行中のpythonプロセス/スレッドを一時停止することが可能になりました。（これには、gdbとptraceを有効にする必要があります）言い換えると、これは、優れた機能を備えた、ブラウザーで直接使用できるpdbの非常に拡張されたバージョンです。

サーバーをインストールして実行し、コードに以下を追加します。

import wdb
wdb.set_trace()

著者によれば、主な違いpdbは次のとおりです。

プロジェクトを知らない人のために、wdbはpdbのようなpythonデバッガーですが、滑らかなWebフロントエンドと次のような多くの追加機能を備えています。

• ソース構文の強調表示
• 視覚的なブレークポイント
• jediを使用したインタラクティブなコード補完
• 永続的なブレークポイント
• マウスのマルチスレッド/マルチプロセッシングサポートを使用したオブジェクトの詳細検査
• リモートデバッグ
• 式を見る
• デバッガコード版
• エラーで中断する人気のWebサーバー統合
• たとえばwerkzeugデバッガーとは対照的に、トレース（死後ではない）中に例外が発生する
• （サポートされているシステムで）コードインジェクションを介して現在実行中のプログラムに侵入する

優れたブラウザベースのユーザーインターフェースを備えています。使う喜び！:)

PyCharmとさまざまなデバッグツールを使用しています。また、初心者向けに簡単に設定できる素敵な記事も用意しています。ここから始めましょう。Djangoプロジェクトの一般的なPDBおよびGUIデバッグについて説明します。誰かが彼らから利益を得ることを願っています。

django開発にAptanaを使用している場合は、次の動画をご覧ください。http：//www.youtube.com/watch？ v = qQh-UQFltJQ

そうでない場合は、使用を検討してください。

ほとんどのオプションはすでに言及されています。テンプレートコンテキストを印刷するために、そのための簡単なライブラリを作成しました。https://github.com/edoburu/django-debugtoolsを参照してください

これを使用して、{% load %}構成なしでテンプレートコンテキストを印刷できます。

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

カスタマイズされたpprint形式を使用して、<pre>タグ内の変数を表示します。

Visual Studio CodeはDjangoアプリのデバッグに最適です。標準のpython launch.jsonパラメーターpython manage.pyはデバッガーがアタッチされた状態で実行されるため、ブレークポイントを設定して、コードを好きなようにステップ実行できます。

ライブコミットに誤ってpdbを追加する可能性がある場合は、＃Koobz回答のこの拡張機能を提案できます。

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

私自身の経験から、2つの方法があります。

1. pdbのような拡張デバッガーであるipdbを使用します。

   import ipdb;ipdb.set_trace()またはbreakpoint() （python3.7から）

2. django shellを使用します。以下のコマンドを使用してください。これは、新しいビューを開発するときに非常に役立ちます。

   python manage.py shell

PDBを使用することを強くお勧めします。

import pdb
pdb.set_trace()

すべての変数の値を調べたり、関数にステップインしたりできます。 https://docs.python.org/2/library/pdb.html

あらゆる種類のリクエスト、応答、データベースへのヒットをチェックアウトするため。django-debug-toolbar https://github.com/django-debug-toolbar/django-debug-toolbarを使用してい ます

ここの他の投稿で述べたように、コードにブレークポイントを設定し、コードをウォークスルーして期待どおりに動作するかどうかを確認することは、すべてがどのように動作するかを理解するまで、Djangoのようなものを学ぶのに最適な方法です。やっています。

これを行うには、WingIdeの使用をお勧めします。他の言及されたIDEと同様に、使いやすく、レイアウトも簡単で、ブレークポイントの設定も簡単です。私はそれの大ファンです。

また、私はPyCharmを使用しています。これは優れた静的コード分析を備えており、問題が存在することに気付く前に問題を見つけるのに役立つ場合があります。

すでに述べたように、django-debug-toolbarは不可欠です-https ://github.com/django-debug-toolbar/django-debug-toolbar

明示的にデバッグまたは分析ツールではありませんが、私のお気に入りの1つは、Django Snippetsのhttps://djangosnippets.org/snippets/290/から入手できるSQL Printing Middlewareです。

これにより、ビューが生成したSQLクエリが表示されます。これにより、ORMが何をしているか、クエリが効率的であるか、コードを作り直す（またはキャッシュを追加する）必要があるかがわかります。

アプリケーションの開発とデバッグ中にクエリのパフォーマンスを監視するのに非常に役立ちます。

もう1つのヒント-SQLステートメントではなく概要のみを表示するように自分用に少し変更しました。開発とテストの際は常に使用します。また、len（connection.queries）が事前定義されたしきい値よりも大きい場合、追加の警告が表示されることも追加しました。

次に、（パフォーマンスまたはクエリ数の観点から）何か問題が発生していることが判明した場合は、SQLステートメントの完全な表示に戻り、何が起こっているのかを正確に確認します。複数の開発者がいる大規模なDjangoプロジェクトで作業しているときに非常に便利です。

pdbまたはを使用しますipdb。これら2つの違いは、ipdbがオートコンプリートをサポートしていることです。

pdbの場合

import pdb
pdb.set_trace()

ipdbの場合

import ipdb
ipdb.set_trace()

改行ヒットnキー、継続ヒットcキーを実行します。を使用して他のオプションを確認するhelp(pdb)

追加の提案。

ビューに手動で注入するのではなく、nosetestsとpdbを一緒に活用できpdb.set_trace()ます。利点は、エラー状態が最初に開始したときに、潜在的にサードパーティのコードで観察できることです。

今日のエラーです。

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

今、これはフォームのコンストラクターを間違えたことを意味し、どのフィールドが問題であるかもよくわかります。しかし、pdbを使用して、テンプレート内でクリスピーフォームが不平を言っていることを確認できますか？

はい、できます。nosetestsで--pdbオプションを使用する：

tests$ nosetests test_urls_catalog.py --pdb

例外（正常に処理されたものを含む）にヒットするとすぐに、pdbは発生した場所で停止し、見回すことができます。

  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)         

さて、クリスピーフィールドコンストラクターに対する私の選択の引数は、タプルのリスト/タプルではなく、リスト内のリストであったことは明らかです。

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

端正なのは、このpdbが私のものではなく、クリスピーのコード内で実行されていることです。手動で挿入する必要はありませんでした。

開発中に、クイック

assert False, value

デバッガーを使用せずに、ビューまたは他の場所で問題を診断するのに役立ちます。