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 <https://github.com/mes3yd/django/commit/eceb9c92419aa66b20399fd2b4bbd99885fc11b2> . -- P.S. Ready for the #ManufacturingRevolution? Watch our two new videos: for Companies <https://hubs.ly/H0cVscY0> & for 3D Printing Services <https://hubs.ly/H0cVt-r0>. P.S.S. Follow the top industry trends <https://www.3yourmind.com/newsletter-sign-up-footer> in our newsletter. * * Meet us at: Technology & innovation <https://innovationdays.com.pl/en/> September 5 - 6 | Lodz, Poland * * TCT Show Birmingham <https://tctshow.com/> | Booth U35 September 25 - 27 | Birmingham, UK * * We're hiring self-driven, innovative, AM-focused people* *here <https://www.3yourmind.com/career?utm_campaign=Career%20Offers&utm_source=Email%20footer&utm_medium=Email%20footer> * *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 -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/b01f87df-2069-422a-9c18-0a7229911d8e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
