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 <[email protected]> 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 [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/20161220071528.GA21882%40sjoerdjob.com.
> > For more options, visit https://groups.google.com/d/optout.
