id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
25070	Provide better (source) context with Django's warnings	Daniel Hahler	nobody	"With Django's (deprecation) warnings it's often hard to find where they
are really coming from.

Adding `ipdb.set_trace()` or printing the stacktrace in `_bootstrap.py:321` seems to be the only viable solution.

For example:

{{{
…/pyenv/lib/python3.4/importlib/_bootstrap.py:321: RemovedInDjango19Warning: django.utils.importlib will be removed in Django 1.9.
  return f(*args, **kwds)
}}}

While you can grep for `django.utils.importlib` in this case, the module must not be necessarily imported/accessed like this, and it is likely to come from an 3rd party app, which needs to be found in the Python path then.


Another example: with something like `from django.contrib.admin.util import unquote` it looks like this:

{{{
…/django18/django/contrib/admin/util.py:7: RemovedInDjango19Warning: The django.contrib.admin.util module has been renamed. Use django.contrib.admin.utils instead.
  ""Use django.contrib.admin.utils instead."", RemovedInDjango19Warning)
}}}


As per the documentation of `warnings.warn` [1] it would be possible to use a
Warning instance instead of a message, and this could then handle extracting
and massaging the current traceback to provide more information / the source.

This might also allow for a global switch that would display a traceback with
all (Django deprecation) warnings, similar to `python -W error`, but without
aborting.


1: https://docs.python.org/2/library/warnings.html#warnings.warn
"	New feature	closed	Core (Other)	1.8	Normal	wontfix			Accepted	0	0	0	0	0	0