Possessive quantifier matches where an ordinary quantifier doesn't

[benrg]

>>> import re
>>> re.fullmatch('(?:ab?c)*', 'a')
>>> re.fullmatch('(?:ab?c)*+', 'a')
<re.Match object; span=(0, 1), match='a'>
>>>

I'm not sure that I completely understand the behavior of the possessive quantifiers, but I think that if R* doesn't match a string then R*+ shouldn't match it, where R is any regex.

Versions tested:

3.12.0b3 (tags/v3.12.0b3:f992a60, Jun 20 2023, 12:25:40) [MSC v.1936 64 bit (AMD64)]
3.11.4 (tags/v3.11.4:d2340ef, Jun  7 2023, 05:45:37) [MSC v.1934 64 bit (AMD64)]
3.11.4 (tags/v3.11.4:d2340ef, Jun  7 2023, 05:30:09) [MSC v.1934 32 bit (Intel)]
3.11.4 (main, Jun 14 2023, 18:33:43) [GCC 10.2.1 20210110]

Linked PRs

• gh-106052: Fix bug in the matching of possessive quantifiers #106515
• [3.11] gh-106052: Fix bug in the matching of possessive quantifiers (gh-106515) #107795
• [3.12] gh-106052: Fix bug in the matching of possessive quantifiers (GH-106515) #107796

[ferdnyc]

If nothing else, the docs claim that

x*+, x++ and x?+ are equivalent to (?>x*), (?>x+) and (?>x?) correspondingly.

And,

>>> import re
>>> re.fullmatch('(?>(?:ab?c)*)', 'a')
>>> 

So, that seems a clear discrepancy.

[arhadthedev]

@ezio-melotti, @serhiy-storchaka (as re module experts)

[serhiy-storchaka]

It is definitely a bug.

The simplest fix would be implementing possessive quantifiers via atomic groups. It may be less efficient, but gives us time to fix the specialized opcode.