Problems with ResolverMatch
|Reported by:||Kevin Christopher Henry||Owned by:||Kevin Christopher Henry|
|Has patch:||yes||Needs documentation:||no|
|Needs tests:||no||Patch needs improvement:||no|
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() 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 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?
Change History (6)
comment:2 Changed 3 years ago by
|Owner:||changed from nobody to Kevin Christopher Henry|
|Status:||new → assigned|