Provide better (source) context with Django's warnings

[Daniel Hahler]

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

[Tim Graham]

I guess this is limited to module level imports. I'm not sure if your proposal is feasible, but Python seems to use the same strategy for deprecating modules (e.g. Lib/imp.py) and so suffers from the same issue. I guess it would be interesting to see if there have been any complaints there and any ideas or work on the issue. It seems like fixing the problem upstream would yield the greatest benefit.

[Tim Graham]

Feel free to reopen if someone can provide an implementation or say why this should be Django specific and not Python specific.