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
22756	Technical 404 could say which view was run, if any.	Keryn Knight <django@…>	jooyous	"Given a view:
{{{
def myview(request):
    raise Http404('test')
}}}
which is mounted at, say, `/a/b/c/`, where `a` and `b` may be url namespaces themselves (ie: urlconfs pulled together via `include('x.y')`) it is laborious to actually establish the callable that was executed, without using django-debug-toolbar; you have to manually traverse from the `ROOT_URLCONF` to wherever the urlpatterns which mount the `myview` are (or use something like django-extensions show_urls; etc etc)

Coming on board to an existing project could be thus made easier, if, when a 404 is thrown by a view (rather than the absence of a view) information was expressed about where to look to alter or fix that.

In `DEBUG`, when the `TECHNICAL_404_TEMPLATE` is used, it ought to be possible to attempt to resolve the `request.path` to a named callable in many circumstances by adding a new value to the `technical_404_response`'s `Context`, using something like the tests debug-toolbar does, which I reproduce here (changed for brevity/structure) in case they change over time:
{{{
name = _(""<no view>"")
try:
    obj = resolve(request.path)
except Resolver404:  # not what debug-toolbar catches; don't know why.
    pass
else:
    if hasattr(obj, '__name__'):
        name = obj.__name__
    elif hasattr(obj, '__class__') and hasattr(obj.__class__, '__name__'):
        name = obj.__class__.__name__

    if hasattr(obj, '__module__'):
        module = obj.__module__
        name = '%s.%s' % (module, name)
}}}"	New feature	closed	Core (URLs)	dev	Normal	fixed			Accepted	1	0	0	0	0	0