[Bug 28766] Dealing with include()

[m...@3yourmind.com]

While working on Bug 287666, I noticed that the point at which the final `ResolverMatch` is created is not always the final point of the URL pattern match. The two cases my tests fail, are points at which an include is done and the pattern is an instance of `URLResolver` not `URLPattern`. This results in incomplete route information:

======================================================================
FAIL: test_converter_resolve (urlpatterns.tests.SimplifiedURLTests) [<object obj
ect at 0x7f017bb25fa0>] (url='/base64/aGVsbG8=/subpatterns/d29ybGQ=/')
----------------------------------------------------------------------
Traceback (most recent call last):
 File "/usr/local/lib/python3.7/unittest/case.py", line 59, in testPartExecutor
   yield
 File "/usr/local/lib/python3.7/unittest/case.py", line 533, in subTest
   yield
 File "/home/melvyn/hg/django-project/tests/urlpatterns/tests.py", line 75, in
test_converter_resolve
   self.assertEqual(match.route, route)
 File "/usr/local/lib/python3.7/unittest/case.py", line 839, in assertEqual
   assertion_func(first, second, msg=msg)
 File "/usr/local/lib/python3.7/unittest/case.py", line 1220, in assertMultiLin
eEqual
   self.fail(self._formatMessage(msg, standardMsg))
 File "/usr/local/lib/python3.7/unittest/case.py", line 680, in fail
   raise self.failureException(msg)
AssertionError: 'base64/<base64:base>/subpatterns/' != 'base64/<base64:base>/sub
patterns/<base64:value>/'
- base64/<base64:base>/subpatterns/
+ base64/<base64:base>/subpatterns/<base64:value>/
?                                  +++++++++++++++

I'm wondering if this is a bug and I've now worked around it, but if there's multiple levels of nesting (as is normal in a Django project), then I'm not sure my fix works. I tried to modify the test, but ran into pickling errors, probably cause the test would need another level of a sub test.

My current reasoning is that if pattern is an instance of URLResolver, sub_match is guaranteed to be an instance of ResolverMatch, which we are rewrapping with the information for this recursion step. So even if there are two directly nested inclusions, the depth-first traversal would ensure the final inclusion is an instance of URLPattern and would have a pattern property of which the string version matches what is in the URLconf.

Do I correctly understand the code, or are there code paths I'm not considering?

The relevant changes are in this commit.

P.S. Ready for the #ManufacturingRevolution?

Watch our two new videos: for Companies & for 3D Printing Services.

P.S.S. Follow the top industry trends in our newsletter.

Meet us at:

Technology & innovation

September 5 - 6  | Lodz, Poland

TCT Show Birmingham  | Booth U35

September 25 - 27  | Birmingham, UK

We're hiring self-driven, innovative, AM-focused people here

3YOURMIND GmbH

Bismarckstraße 10-12 | 10625 Berlin | Germany

VAT ID - USt-IdNr. gemäß § 27 a Umsatzsteuergesetz: DE296555110

Company with its registered seat in - Sitz der Gesellschaft: Berlin

Register court - Registergericht: Amtsgericht Charlottenburg (Berlin)

Register number - Registernummer: HRB 160616

Executive Manager - Geschäftsführer: Aleksander Ciszek & Stephan Kühr