[issue22493] Deprecate the use of flags not at the start of regular expression

Ales Kvapil added the comment: See also https://bugs.python.org/issue33658 -- ___ Python tracker ___

[issue22493] Deprecate the use of flags not at the start of regular expression

Ales Kvapil added the comment: Maybe there should be introduced some method to merge patterns as just piping patterns will not work: pats = [r'(?m)^line.continues$', r'(?s)begin.*?end'] re.compile('|'.join(pats)) -- nosy: +aleskva

[issue22493] Deprecate the use of flags not at the start of regular expression

Changes by Donald Stufft : -- pull_requests: +949 ___ Python tracker ___ ___

[issue22493] Deprecate the use of flags not at the start of regular expression

Roundup Robot added the comment: New changeset c04a56b3a4f2 by Serhiy Storchaka in branch '3.6': Issue #22493: Updated an example for fnmatch.translate(). https://hg.python.org/cpython/rev/c04a56b3a4f2 New changeset ded9a3c3bbb6 by Serhiy Storchaka in branch 'default': Issue #22493: Updated an

[issue22493] Deprecate the use of flags not at the start of regular expression

Serhiy Storchaka added the comment: Patch LGTM (but I changed tests a little). Thanks Tim! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue22493] Deprecate the use of flags not at the start of regular expression

Roundup Robot added the comment: New changeset c35a528268fd by Serhiy Storchaka in branch '3.6': Issue #22493: Warning message emitted by using inline flags in the middle of https://hg.python.org/cpython/rev/c35a528268fd New changeset 9d0f4da4d531 by Serhiy Storchaka in branch 'default': Issue

[issue22493] Deprecate the use of flags not at the start of regular expression

Tim Graham added the comment: Yes, I found that Django needs an update to support that syntax in URLpatterns. Thanks. -- ___ Python tracker ___

[issue22493] Deprecate the use of flags not at the start of regular expression

Matthew Barnett added the comment: I downloaded Python 3.6.0b1 not long after it was released and it works for me: >>> re.match('(?i:CaseInsensitive)', 'caseinsensitive') <_sre.SRE_Match object; span=(0, 15), match='caseinsensitive'> -- ___ Python

[issue22493] Deprecate the use of flags not at the start of regular expression

Tim Graham added the comment: Adding an updated patch. I guess the (?i:CaseInsensitive) syntax isn't merged yet? I tried it but it didn't work. It might be premature to proceed with this deprecation if that alternative isn't already present. Is there an issue for it? -- Added file:

[issue22493] Deprecate the use of flags not at the start of regular expression

Serhiy Storchaka added the comment: In tests you can either add re.escape(), or escape special characters manually (r'\(\?i\)'). What you prefer. -- ___ Python tracker

[issue22493] Deprecate the use of flags not at the start of regular expression

Serhiy Storchaka added the comment: Thanks Tim, this is great idea! I consider this as usability bug and going to apply a fix to 3.6. But regular expression can be generated and be very long. I think it should be truncated before including in a warning message. As for Django, you can use

[issue22493] Deprecate the use of flags not at the start of regular expression

Changes by Serhiy Storchaka : -- resolution: fixed -> stage: resolved -> patch review status: closed -> open ___ Python tracker

[issue22493] Deprecate the use of flags not at the start of regular expression

Tim Graham added the comment: Looks like we could remove the '^', but it doesn't resolve the deprecation warnings. The inline flags in `pattern` still need to be moved before `_prefix`. -- ___ Python tracker

[issue22493] Deprecate the use of flags not at the start of regular expression

Matthew Barnett added the comment: @Tim: Why are you using re.search with '^'? Does the pattern that's passed in ever contain '(?m)'? If not, re.match without '^' is better. -- ___ Python tracker

[issue22493] Deprecate the use of flags not at the start of regular expression

Tim Graham added the comment: And on further investigation, I'm not sure how to fix the deprecation warnings in Django. We have a urlpattern like this: url(r'^(?i)CaseInsensitive/(\w+)', empty_view, name="insensitive"), The regex string r'^(?i)CaseInsensitive/(\w+)' is later substituted in

[issue22493] Deprecate the use of flags not at the start of regular expression

Tim Graham added the comment: Could we include the offending pattern in the deprecation message? I'm attaching a proposed patch. With that patch I can more easily find the offending pattern, whereas before I had no idea: django/django/urls/resolvers.py:101: DeprecationWarning: Flags not at

[issue22493] Deprecate the use of flags not at the start of regular expression

Changes by Serhiy Storchaka : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue22493] Deprecate the use of flags not at the start of regular expression

Roundup Robot added the comment: New changeset 31f8af1c3567 by Serhiy Storchaka in branch 'default': Issue #22493: Inline flags now should be used only at the start of the https://hg.python.org/cpython/rev/31f8af1c3567 -- nosy: +python-dev ___ Python

[issue22493] Deprecate the use of flags not at the start of regular expression

Serhiy Storchaka added the comment: Updated patch that deprecates flags not at the start. fnmatch.translate() now uses scoped flags (issue433028). -- Added file: http://bugs.python.org/file44526/re_deprecate_nonstart_flags2.patch ___ Python tracker

[issue22493] Deprecate the use of flags not at the start of regular expression

Changes by Serhiy Storchaka : -- assignee: -> serhiy.storchaka versions: +Python 3.6 -Python 3.5 ___ Python tracker ___

[issue22493] Deprecate the use of flags not at the start of regular expression

Serhiy Storchaka added the comment: That sounds a bit random. It wouldn't totally address the discrepancy with regex, would it? No, it will not totally address the discrepancy with regex, but at least it will allow as to change the behavior of flags in subpatterns. And we always can

[issue22493] Deprecate the use of flags not at the start of regular expression

Serhiy Storchaka added the comment: Here is alternative, much simpler, patch. It deprecates only flags in nested subpatterns. No changes needed in tests and other stdlib modules. It is very unlikely that it is used in third party code. -- Added file:

[issue22493] Deprecate the use of flags not at the start of regular expression

Antoine Pitrou added the comment: Here is alternative, much simpler, patch. It deprecates only flags in nested subpatterns. That sounds a bit random. It wouldn't totally address the discrepancy with regex, would it? MRAB, what do you think on this topic? --

[issue22493] Deprecate the use of flags not at the start of regular expression

Matthew Barnett added the comment: I think the simplest and clearest approach from the user's point of view is just to deprecate inline flags that are not at the start of the pattern. In practice, they almost invariably occur at the start anyway, although I do remember once seeing a pattern

[issue22493] Deprecate the use of flags not at the start of regular expression

New submission from Serhiy Storchaka: The meaning of inline flags not at the start of regular expression is ambiguous. Current re implementation and regex in the V0 mode enlarge the scope to all expression. In V1 mode in regex they affect only the end of the expression. I propose to