[issue20998] fullmatch isn't matching correctly under re.IGNORECASE

Serhiy Storchaka added the comment: Thank you Matthew for your contribution. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker __

[issue20998] fullmatch isn't matching correctly under re.IGNORECASE

Roundup Robot added the comment: New changeset 6267428afbdb by Serhiy Storchaka in branch '3.4': Issue #20998: Fixed re.fullmatch() of repeated single character pattern http://hg.python.org/cpython/rev/6267428afbdb New changeset bcf64c1c92f6 by Serhiy Storchaka in branch 'default': Issue #20998:

[issue20998] fullmatch isn't matching correctly under re.IGNORECASE

Changes by Serhiy Storchaka : -- assignee: -> serhiy.storchaka ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue20998] fullmatch isn't matching correctly under re.IGNORECASE

Serhiy Storchaka added the comment: Gareth, this is unrelated issue. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsub

[issue20998] fullmatch isn't matching correctly under re.IGNORECASE

Serhiy Storchaka added the comment: > After stepping through the code for that regex that fails, I concluded > that the condition shouldn't depend on ctx->match_all at that point > after all. Tests are passed without this check. But I'm not sure it is not needed. At least without this check the

[issue20998] fullmatch isn't matching correctly under re.IGNORECASE

Gareth Gouldstone added the comment: fullmatch() is not yet implemented on the regex scanner object SRE_Scanner (issue 21002). Is it possible to adapt this patch to fix this omission? -- nosy: +Gareth.Gouldstone ___ Python tracker

[issue20998] fullmatch isn't matching correctly under re.IGNORECASE

Matthew Barnett added the comment: > > -(!ctx->match_all || ctx->ptr == state->end)) { > > +ctx->ptr == state->end) { > > Why this check is not needed anymore? > After stepping through the code for that regex that fails, I concluded that the condition shouldn't

[issue20998] fullmatch isn't matching correctly under re.IGNORECASE

Serhiy Storchaka added the comment: Both patch are almost equivalent (my patch is much simpler but perhaps Matthew's approach is more correct in long perspective). Unfortunately Rietvield doesn't work with Matthew's patch, so I have added my comments here. > -(!ctx->match_all

[issue20998] fullmatch isn't matching correctly under re.IGNORECASE

Matthew Barnett added the comment: FWIW, here's my own attempt at a patch. -- Added file: http://bugs.python.org/file34538/issue20998.patch ___ Python tracker ___ ___

[issue20998] fullmatch isn't matching correctly under re.IGNORECASE

Serhiy Storchaka added the comment: Here is a patch. -- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file34537/sre_fullmatch_repeated_ignorecase.patch ___ Python tracker _

[issue20998] fullmatch isn't matching correctly under re.IGNORECASE

Changes by Serhiy Storchaka : -- nosy: +serhiy.storchaka stage: -> needs patch versions: +Python 3.5 ___ Python tracker ___ ___ Pytho

[issue20998] fullmatch isn't matching correctly under re.IGNORECASE

Changes by Nathan West : -- type: -> behavior ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pyt

[issue20998] fullmatch isn't matching correctly under re.IGNORECASE

New submission from Nathan West: I have the following regular expression: In [2]: regex = re.compile("ME IS \w+", re.I) For some reason, when using `fullmatch`, it doesn't match substrings longer than 1 for the '\w+': In [3]: regex.fullmatch("ME IS L") Out[3]: <_sre.SRE_Match object; span=(0,