Why Does a Repeated Capture Group Return these Strings?

Question

Can someone explain why following returns \'cc\'?

>>> re.match(\'(..)+\', \'aabbcc\').group(1)
\'cc\'

I was told that because it p

Answer 1

Repeated Capture Group: The Group Number Stays the Same

The group defined by (..) is Group 1. The + quantifier repeats it. Every time the engine is able to repeat the group (matching two characters), Group 1 gets overwritten.

• When the engine starts to match, it captures aa to Group 1
• It then captures bb to Group 1
• It then captures cc to Group 1.

When you inspect Group 1, the engine returns cc. All other captures are lost.

(The exception is the .NET engine, which also returns cc but also allows you to inspect intermediate captures thanks to the CaptureCollection object. It would contain aa, bb and cc.)

With (..)+(...), Why does Group 1 Contain aa? Backtracking!

To understand this, we again need to follow the path of the regex engine.

• Once again, when the engine starts to match, it captures aa to Group 1
• Again, it repeats the (..) group and captures bb to Group 1
• Again, it repeats the (..) group and captures cc to Group 1
• The engine now tries to match (...). It fails: there are no characters left to consume.
• The engine backtracks both in the string and in the regex pattern. The + means one or more times, and we matched .. three times, so we can give one up, or even two. At this stage, the engine gives up the last match of the quantified (..)+ group, which is cc. We are back to when Group 1 was bb.
• The engine tries to match (...) again. There are only two characters left: cc, so it fails again.
• The engine backtracks by giving up the last match of the quantified (..)+ group, which is bb. At this stage, Group 1 is aa again.
• The engine tries to match (...) again. It succeeds: Group 2 is bbc, and Group 1 is aa

Reference

• Capture Group Numbering & Naming: The Gory Details
• Backreferences