Ignore, rather than disallow, negative lookahead assertions

[charles@…]

At present, django.utils.regexhelper.normalize() is defined and documented to raise an exception on encountering lookahead and lookbehind matches in the name of reversability. This behaviour unnecessarily restricts the range of valid configurations.

Consider the following case:

url(r'^(?P<city>[-\w._])/', name='city-landing'),

One may wish to assert that certain inputs are *certainly not* cities, and should never match this (in my particular use case, the desired outcome is actually a Resolver404, such that adding an additional, earlier url() entry to the urlconf is not an option):

url(r'^(?!NotACity)(?P<city>[-\w._])/', name='city-landing'),

This *does* mean that reverse('city-landing', kwargs={'name': 'NotACity'}) will result in an invalid result (a URL which, when resolved, does not in fact match the given reversed string). However, such a case clearly constitutes user error -- as the application developer trying to request a city-landing URL for NotACity is asking the impossible -- and does not constitute cause for making such patterns unsupported.

[charles@…]

Initial proposed patch

[Aymeric Augustin]

Reading the comment on #2977 and duplicate tickets, I think we can accept this. I'm a bit surprised that the patch is so simple, but why not.

Until now, lookahead/behind assertions were forbidden, so it can't be backwards incompatible.

The docs probably needs updating.

[Bas Peschier]

It was never documented that it was not allowed except for the source comments above normalize. These assertions are part of a valid regular expression, so I only added a release note.

[Tim Graham]

Looks good, pending some cosmetic comments.

[Tim Graham <timograham@…>]

In b4382b7:

Fixed #16362 -- Allowed lookaround assertions in URL patterns.