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 21043 resolve doesn't handle lazily evaluated reverses Keryn Knight "the following code generates an exception, which isn't documented as a caveat of using `reverse_lazy` (or being given a lazy proxy when you might've expected to receive a string, because the code is external and outside your control): {{{ >>> from django.core.urlresolvers import reverse_lazy, resolve >>> proxy = reverse_lazy('admin:index') >>> resolve(proxy) Traceback (most recent call last): File """", line 1, in File ""/django/core/urlresolvers.py"", line 453, in resolve return get_resolver(urlconf).resolve(path) File ""/django/core/urlresolvers.py"", line 315, in resolve match = self.regex.search(path) TypeError: expected string or buffer }}} The fix is dirt simple in userland, because you can just call str/unicode/force_unicode on the proxy to evaluate it into a path. The problem lies in the path given to `resolve` being directly handed off to the `re` module, without being checked for validity. {{{ >>> from django.core.urlresolvers import reverse_lazy, resolve >>> proxy = reverse_lazy('admin:index') >>> from django.utils.encoding import force_unicode >>> resolve(force_unicode(proxy)) ResolverMatch(func=, args=(), kwargs={}, url_name='index', app_name='admin', namespace='admin') }}} Both the above assume a project with `django.contrib.admin` in INSTALLED_APPS, because it's the easiest way of ensuring there's views to resolve :) I think that the issue should be documented; it's not something that's common, and if you encounter it, one would hope you've got a reasonable idea about where the problem lies, and it's probably safer to document it than promote forced evaluation into the `resolve` method of `RegexURLResolver` Marking as easy pickings on that basis." Bug closed Core (URLs) dev Normal fixed urlresolvers resolve reverse Accepted 1 0 0 0 1 0