これは本当に苦痛です。この問題は 2 回発生しましたが、まだ適切な解決策が見つかりません。
__init__
これは、フォームのメソッドをオーバーライドする場合の安全なデバッグの例です。
class MyForm(forms.ModelForm):
def __init__(self, *args, **kwargs):
super(MyForm, self).__init__(*args, **kwargs)
# Disable form validation for debugging purposes unless the
# object is fully initialized. Set breakpoints BELOW this line.
del self._errors
# Write some additional initializations here, debug safely.
...
# Initialization is finished. Enable form validation.
self._errors = None
基本フォーム クラスをデバッグする場合は、同じ方法で Django コードにパッチを適用します。
デバッグ後にこの追加コードを残すか削除することができます - これは大きな違いはありません。ただし、将来これが必要になる場合に備えて残しておくことをお勧めします。
それで、ここで実際に何が起こっているのですか?
(Django プロジェクト サイトのバグレポート: https://code.djangoproject.com/ticket/24710 )
問題は、Django のBaseForm.errors
プロパティ ゲッター (実際には@property
デコレータを使用したメソッド) が多すぎることです。プロパティ値full_clean()
を変更するメソッドを呼び出して、 getter が呼び出しを繰り返しても同じ作業を繰り返さないようにします。_errors
errors
class BaseForm(object):
@property
def errors(self):
if self._errors is None:
self.full_clean()
return self._errors
def full_clean(self):
self._errors = ErrorDict()
...
もちろん、PyCharm デバッガーはプロパティが単なるプロパティであると想定しており、オブジェクトの内部状態に重大な変更を加えることはありません。そのため、デバッガーはerrors
ゲッターを呼び出して、メソッドをデバッグするときに「変数」ウィンドウにその値を表示します__ini__
。これにより、通常の実行フローが中断されます。
get_error()
(これが、プロパティではなく、このような場合のようなメソッドを定義する必要がある理由です)
__init__
考えられる 1 つの提案は、フォームのメソッド内でのブレークポイントと段階的な実行を避けることです。ただし、本当にデバッグする必要がある場合は、コードを変更して_errors
、段階的な実行中にプロパティが存在しないようにします。full_clean
これにより、メソッドの呼び出しが防止されます。PyCharm デバッガーは、プロパティにアクセスしようとするたびにエラーを受け取りますerrors
。
注:プロパティは、メソッドerrors
の外部であっても、実行が一時停止されている任意のステップで評価される場合があります。__init__
すべてのフィールドがすでに完全に初期化されている場合、これはおそらく結果に影響しません (メソッドでのみこれを行うことを忘れないでください__init__
)。is_valid
ただし、メソッド呼び出しに到達する前にフォームが検証されたように見えるため、フォーム検証プロセスをデバッグできない場合があります。この場合、full_clean
メソッド内にブレークポイントを設定し、フォームのインスタンス化ポイントとこのブレークポイントの間で停止しないでください。