[Django] #25070: Provide better (source) context with Django's warnings

[Django]

#25070: Provide better (source) context with Django's warnings
------------------------------+--------------------
Reporter: blueyed | Owner: nobody
Type: New feature | Status: new
Component: Core (Other) | Version: 1.8
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
------------------------------+--------------------
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

--
Ticket URL: <https://code.djangoproject.com/ticket/25070>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

[Django]

#25070: Provide better (source) context with Django's warnings

------------------------------+--------------------------------------

Reporter: blueyed | Owner: nobody
Type: New feature | Status: new
Component: Core (Other) | Version: 1.8

Severity: Normal | Resolution:
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0

Easy pickings: 0 | UI/UX: 0

------------------------------+--------------------------------------
Changes (by timgraham):

* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0

Comment:

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.

--
Ticket URL: <https://code.djangoproject.com/ticket/25070#comment:1>

[Django]

#25070: Provide better (source) context with Django's warnings

------------------------------+------------------------------------
Reporter: blueyed | Owner: nobody
Type: New feature | Status: closed

Component: Core (Other) | Version: 1.8

Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage: Accepted

Has patch: 0 | Needs documentation: 0

Needs tests: 0 | Patch needs improvement: 0

Easy pickings: 0 | UI/UX: 0

------------------------------+------------------------------------
Changes (by timgraham):

* status: new => closed
* resolution: => wontfix
* stage: Unreviewed => Accepted

Comment:

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

--
Ticket URL: <https://code.djangoproject.com/ticket/25070#comment:2>