Problems with ResolverMatch
|Reported by:||marfire||Owned by:||marfire|
|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(). 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:1 Changed 3 years ago by marfire
- Cc k@… added
- Needs documentation unset
- Needs tests unset
- Patch needs improvement unset
- Type changed from Uncategorized to Bug
comment:2 Changed 3 years ago by marfire
- Has patch set
- Owner changed from nobody to marfire
- Status changed from new to assigned