Testing and tracking down Warnings in Django

Warnings are often suppressed through many layers of control mechanisms in Python and Django. However, you should really be aware of these and clean them up once in a while!

In other cases, the Warnings reflect an inconsistent state, such as if you are mixing naive and timezone-aware variables. It can be a real pain to track down RuntimeWarning because it doesn't leave a nice stack trace. The scenario could be that you have assigned a naive DateTime to a field, and the db layer is complaining at runtime.

However, you can run python in a mode where Warning-types raise exceptions with full stack traces. Use the following syntax:

python -W error:"":RuntimeWarning:django.db.models.fields:0 manage.py runserver
  • 'error' means that python should raise an exception - this is what we want!

  • 'RuntimeWarning' means to trigger when such is raised - you can also simply put 'Warning' to trigger for all Warning types.

  • 'django.db.models.fields' means activate for this module (you need the full path). Notice that simply putting 'django' does not activate for all of django, you need to put the specific module or simply '""' to enable for all of Python (which might render some interesting Warning goodies that you have never seen!).

  • '0' means any line (you probably don't need)

You can read more in Python Documentation chapter: Warning Control.