{{{
import os
from django.conf import settings
from django.http import HttpResponse
from django.urls import path, reverse, resolve
fname = os.path.splitext(os.path.basename(__file__))[0]
urlpatterns = [
path('<int:pk>/', lambda r, **kwargs: HttpResponse('Hello, world!'),
name='testurl'),
]
if __name__ == "__main__":
settings.configure(DEBUG=True, MIDDLEWARE_CLASSES=[],
ROOT_URLCONF=fname)
# Works
reverse('testurl', kwargs={'pk': 4})
# Raises Resolver404
resolve('<int:pk>/')
}}}
This holds for Django 2.2, Django 3.0, Django 3.1 and Django 3.2a1.
I've pdb'ed my way into the django code and the problem seems to be that
when `URLResolver.resolve()` gets around to running
`RoutePattern.match(path)`, the path looks like `"'<int:pk>/'"` but the
regex it is checked against, stored on the RoutePattern instance, looks
like `re.compile('^(?P<pk>[0-9]+)/$')`, which obviously will never match.
(I'm using `resolve()` in a unittest to check that manually created views
with externally known paths are properly installed in the urlconf. I get
the paths to test from `django_extensions`'s `show_urls`.)
--
Ticket URL: <https://code.djangoproject.com/ticket/32402>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* type: Uncategorized => Bug
--
Ticket URL: <https://code.djangoproject.com/ticket/32402#comment:1>
* status: new => closed
* resolution: => invalid
* component: Uncategorized => Core (URLs)
Comment:
`resolve()` can be used for resolving URL path not for resolving URL
patterns, e.g. `resolve('/6/')` works as expected, see
[https://docs.djangoproject.com/en/dev/ref/urlresolvers/#resolve docs].
Please don't use Trac as a support channel. Closing per
TicketClosingReasons/UseSupportChannels.
--
Ticket URL: <https://code.djangoproject.com/ticket/32402#comment:2>