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