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-insensit
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 chara
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
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
I think the current implementation means they affect all included children.
On 20 December 2016 at 07:15, Sjoerd Job Postmus wrote:
> On Mon, Dec 19, 2016 at 08:23:09AM +, Adam Johnson wrote:
> > >
> > > I guess the "safest" option is to keep the code around and let this
> > > feature die w
On Mon, Dec 19, 2016 at 08:23:09AM +, 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
> > ab
>
> 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
Only case insensitive matching was tested in the URL tests and none of this
is documented. That's the only flag where I see a straightforward use case
(but I avoid regexes of any complexity and didn't even know what the flags
were for until I just looked them up), even if case-insensitive URLs a
Since they were used in several places in Django's test suite I feel like
it's highly likely they're out there in use in the wild.
Also if Django were to remove it, it would both 1) be a bit surprising
compared to the re module, as it's an implementation detail that the
urlparser prefixes '^/' an
Python deprecated usage of flags not at the start of a regular expression
[0], e.g. 'CaseInsensitive(?i)' instead of '(?i)CaseInsensitive'.
Deprecation warnings shows up in a few URL tests that are using (?i) to get
case-insensitive matching of URLpatterns. However, because the URL resolver
pre
10 matches
Mail list logo
