> > 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. On 18 December 2016 at 23:44, Tim Graham <timogra...@gmail.com> wrote: > 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 > aren't a good practice. From the W3C [0]: "URLs in general are > case-sensitive (with the exception of machine names). There may be URLs, or > parts of URLs, where case doesn't matter, but identifying these may not be > easy. Users should always consider that URLs are case-sensitive."). 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. > > [0] https://www.w3.org/TR/WD-html40-970708/htmlweb.html > > Here are the other flag values, feel free to offer a use case if you have > one: > > re.I -- match case insensitive > > re.L -- The use of this flag is discouraged as the locale mechanism is > very unreliable, and it only handles one “culture” at a time anyway; you > should use Unicode matching instead, which is the default in Python 3 for > Unicode (str) patterns. This flag makes sense only with bytes patterns. > > re.M -- MULTILINE -- When specified, the pattern character '^' matches at > the beginning of the string and at the beginning of each line (immediately > following each newline); and the pattern character '$' matches at the end > of the string and at the end of each line (immediately preceding each > newline). By default, '^' matches only at the beginning of the string, and > '$' only at the end of the string and immediately before the newline (if > any) at the end of the string. > > re.S -- DOTALL - Make the '.' special character match any character at > all, including a newline; without this flag, '.' will match anything except > a newline. > > re.U -- Unicode -- these are redundant in Python 3 since matches are > Unicode by default for strings > > On Sunday, December 18, 2016 at 4:18:33 PM UTC-5, Adam Johnson wrote: >> >> 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 '^/' and 2) need a deprecation path that would require >> code to work in Python 3.6 that's equivalent to implementing the feature, >> so why not keep said code around? >> >> On 16 December 2016 at 19:19, Tim Graham <timog...@gmail.com> wrote: >> >>> 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 prefixes '^/' [or get_script_prefix()] to all patterns [1], the >>> warning happens even if the regex group is at the start of a urlpattern, >>> e.g. >>> >>> /home/tim/code/django/django/urls/resolvers.py:464: DeprecationWarning: >>> Flags not at the start of the expression ^\/(?i)CaseInsensiti (truncated) >>> if re.search('^%s%s' % (re.escape(_prefix), pattern), candidate_pat % >>> candidate_subs, re.UNICODE): >>> >>> A better sense of what's affected can be seen on my PR that removes >>> support for the ignored groups [2]. All this landed in 2008 in Malcolm's >>> rewrite of URL parsing [3]. >>> >>> I'm not sure if any of these groups are used in URLpatterns in the wild >>> or if it's okay to proceed with the removal. To keep the feature, I imagine >>> Django would need to do some extraction of flags from URLpatterns and put >>> them at the start of patterns, but I'm not too sure. >>> >>> Thanks for your feedback. >>> >>> [0] http://bugs.python.org/issue22493 >>> [1] https://github.com/django/django/blob/5d28fef8f9329e440ee67c >>> efc900dbf89f4c524c/django/urls/resolvers.py#L464 >>> [2] https://github.com/django/django/pull/7701 >>> [3] https://github.com/django/django/commit/a63a83e5d88cd1696d1c >>> 40e89f254f69116c6800 >>> >>> -- >>> 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/ms >>> gid/django-developers/a1489dba-c602-4df4-87c4-3edf2ada702e% >>> 40googlegroups.com >>> <https://groups.google.com/d/msgid/django-developers/a1489dba-c602-4df4-87c4-3edf2ada702e%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> Adam >> > -- > 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/a5479564-7315-468d-8792- > 81849feed9d7%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/a5479564-7315-468d-8792-81849feed9d7%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Adam -- 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/CAMyDDM3WJaYFEb5XGmJNVq4WdA28V%3DfKt4oEX1Aj7NJ-GZefRg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
