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
> <javascript:>> 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 <javascript:>.
> > > To post to this group, send email to django-d...@googlegroups.com
> <javascript:>.
> > > 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/d567e297-2afd-405d-a139-aeb9f2375924%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
