I created a ticket and pull request for the deprecation: https://code.djangoproject.com/ticket/27648 https://github.com/django/django/pull/7749
On Friday, December 23, 2016 at 10:22:40 AM UTC-5, Tim Graham wrote: > > I found a flask thread [0] where Armin Ronacher said this about > case-insensitive URLs: > > "I think it's a horrible idea. It destroys your caching and creates > multiple entries for search engines." > > Adam Oakman added: "Agreed. My personal method is to code the 404 handler > to look for uppercase characters and redirect to a lowercase equivalent to > catch such cases. > > I propose to deprecate usage of these regex groups and offer no > replacement besides this advice. > > [0] > http://librelist.com/browser/flask/2011/6/24/case-insensitive-routing/#ea14dfeac18a440b8a792358691f15e0 > > On Wednesday, December 21, 2016 at 10:21:04 AM UTC-5, Tim Graham wrote: >> >> I learned a couple more things: >> - The end of the Python deprecation is TBA (not in 3.7 as I stated >> before), perhaps not until Python 2.7 is unsupported (4 more years). >> - Using (?i) in urlpatterns is promoted at >> http://stackoverflow.com/questions/1515634/case-insensitive-urls-for-django >> >> If case-insensitive URL matching is going to before a more formal >> feature, maybe it makes sense to either 1) have a global "setting" that >> makes all patterns case-insensitive or 2) restrict the case-insensitive >> designation to urlpatterns in the ROOT_URLCONF (to avoid the ambiguous >> nesting problem that Marten mentioned). >> >> Alternatively, we could decide that it's not Django's job to provide this >> (not sure if other frameworks do -- personally I don't see case-insensitive >> URLs as a best practice) and instead suggest configuring your front-end >> webserver (e.g. Apache mod_rewrite) to handle it such as by converting URLs >> to lowercase before passing them to Django. A Django middleware might also >> be able to do this, idea from [2]. >> >> related links: >> https://groups.google.com/d/topic/django-users/X0MkPp-_R-Q/discussion "I >> would like to make urls of my site case-insensitive." >> >> http://stackoverflow.com/questions/14814419/how-do-i-make-urls-case-insensitive-in-linux-server >> >> - "How do I make URLs case insensitive in Linux server" >> [2] >> https://groups.google.com/d/topic/django-developers/UehV6WZhJTM/discussion >> - Case-insensitive URLS >> >> On Tuesday, December 20, 2016 at 1:01:44 PM UTC-5, Marten Kenbeek wrote: >>> >>> This issue is actually limited to reverse(). When resolving urls, each >>> nested regex is matched against the url separately, so you can just apply >>> the flags to the "local" regex pattern, and get: >>> >>> a/c/ >>> a/C/ >>> a/b/ >>> >>> matching, but not: >>> >>> A/c/ >>> A/C/ >>> A/b/ >>> >>> The behaviour for reverse() can be a problem. For example, consider the >>> following patterns: >>> >>> url(r'([A-Z]+)/', include('b')) >>> >>> and in b: >>> >>> url(r'([A-Z]+)/$', blah, name='blah', flags=re.I) >>> >>> Since the flag can only apply to the combined pattern >>> r'([A-Z]+)/([A-Z]+)/$', we can either incorrectly reject reverse('blah', >>> args=('A', 'b')), or we can return an invalid url for reverse('blah', >>> args=('a', 'b')). >>> >>> This seems to be a problem with the current implementation as well, >>> which would return an invalid url for reverse('blah', args=('a', 'b')), >>> since (?i) applies to the whole pattern regardless of its position. >>> >>> re.I is probably the only flag we need to care about. re.U is always >>> used, use of re.L is discouraged, and re.M/re.S only apply to multi-line >>> strings. >>> >>> On Tuesday, December 20, 2016 at 5:50:39 PM UTC+1, Shai Berger wrote: >>>> >>>> I think part of Sjoerd's point was that current implementation also >>>> means that >>>> including the flag in a child affects parents -- but only with regard >>>> to said >>>> child. So, if you have >>>> >>>> url('a/', include("b")) >>>> >>>> and in b: >>>> >>>> url('b/$', blah), >>>> url('c/$', bleh, flags=re.I), >>>> >>>> then the valid urls include >>>> >>>> a/c/ >>>> A/c/ >>>> a/C/ >>>> A/C/ >>>> a/b/ >>>> >>>> but not >>>> >>>> A/b/ >>>> >>>> which is a bit odd. >>>> >>>> On Tuesday 20 December 2016 12:21:18 Adam Johnson wrote: >>>> > I think the current implementation means they affect all included >>>> children. >>>> > >>>> > On 20 December 2016 at 07:15, Sjoerd Job Postmus <sjoe...@sjec.nl> >>>> wrote: >>>> > > On Mon, Dec 19, 2016 at 08:23:09AM +0000, Adam Johnson wrote: >>>> > > > > I guess the "safest" option is to keep the code around and let >>>> this >>>> > > > > >>>> > > > > feature die when the deprecation ends in Python 3.7 (and >>>> meanwhile >>>> > > > > see >>>> > > >>>> > > if >>>> > > >>>> > > > > anyone notices the deprecation warning in their code and files >>>> a >>>> > > > > ticket about it). The only extra work compared to removing this >>>> now >>>> > > > > is >>>> > > >>>> > > silencing >>>> > > >>>> > > > > the Python deprecation warnings in the Django tests in the >>>> meantime. >>>> > > > >>>> > > > Sounds fair. Flags could always be added to *url()* as an extra >>>> > > >>>> > > parameter. >>>> > > >>>> > > How would that work with nested URL patterns? Would adding a flag >>>> also >>>> > > apply that for the "parent" and/or "child" patterns? Would that >>>> also >>>> > > work correctly for reverse? >>>> > > >>>> > > Asking because I seriously don't know. >>>> > > >>>> > > -- >>>> > > 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 django-develop...@googlegroups.com. >>>> > > To post to this group, send email to django-d...@googlegroups.com. >>>> > > 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/20161220071528.GA21882%40sjoerdjob.com. >>>> > > For more options, visit https://groups.google.com/d/optout. >>>> >>> -- 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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. 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/46aa261e-8cb9-4b34-ab7d-16bd52d66386%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
