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
21157	Problems with ResolverMatch	Kevin Christopher Henry	Kevin Christopher Henry	"One problem is that `ResolverMatch.func` can sometimes be a string rather than a callable.

The ultimate source of this is that `resolve()` is using the same `get_callable()` algorithm as `reverse()`. `reverse()` has to guess whether it is being passed a string import path or a string pattern name, and it does this by looking for a `.` in the string. When `resolve()` uses this same function and passes in an unqualified path name, it's treated as a pattern name and returned as is. But since `resolve()` knows that it's dealing with a view, it would be better in this case to always return a callable (or raise an import Exception).

I would say this is definitely a bug in the implementation (as opposed to the documentation) except that the author of `urlpatterns_reverse.tests.ResolverMatchTests.test_urlpattern_resolve()` clearly anticipated this behavior.

Another problem is that the [https://docs.djangoproject.com/en/dev/ref/urlresolvers/ documentation] says that `url_name` is ""The name of the URL pattern that matches the URL"", whereas `ResolverMatch` will insert the string path to the view here if no name was defined. I think the documented behavior makes more sense - why conflate the view path with the pattern name here?"	Bug	closed	Core (URLs)	dev	Normal	fixed		k@…	Accepted	1	0	0	0	0	0