gh-152026: Support redefinition of named capture groups#152027
Open
serhiy-storchaka wants to merge 1 commit into
Open
gh-152026: Support redefinition of named capture groups#152027serhiy-storchaka wants to merge 1 commit into
serhiy-storchaka wants to merge 1 commit into
Conversation
The same name can now be used for more than one capturing group. All such
groups share a single group number; the name and number refer to whichever
of the groups matched (the last one, if more than one matched). The group's
width range spans all the definitions.
This is chiefly useful for giving the same name to corresponding groups in
alternative spellings of a pattern:
(?P<m>\d+)/(?P<d>\d+)/(?P<y>\d+)|(?P<y>\d+)-(?P<m>\d+)-(?P<d>\d+)
Previously each group name had to be unique within a regular expression.
Sharing a group number also requires a fix in the matching engine. Outside
of repeats the matcher restores capture-group marks lazily, only rewinding
the lastmark high-water index, which assumes each group number is written at
a single place in the bytecode. A reused group number could otherwise leak a
mark from a branch that matched and was then backtracked away, or raise
SystemError. Reused group numbers are detected during code validation, and
such patterns save and restore the full mark array on backtracking, exactly
as is already done inside repeats; other patterns are unaffected.
The same flag also lets the possessive quantifier handler request mark saving
directly, replacing the placeholder repeat context that was previously
installed for that purpose (the pythongh-101955 workaround), so a possessive repeat
no longer allocates a repeat context.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Documentation build overview
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The same name can now be used for more than one capturing group in a regular expression. All such groups share a single group number; the name and number refer to whichever of the groups matched (the last one, if more than one matched). This is chiefly useful for giving the same name to corresponding groups in alternative spellings of a pattern, e.g.
(?P<m>\d+)/(?P<d>\d+)/(?P<y>\d+)|(?P<y>\d+)-(?P<m>\d+)-(?P<d>\d+). Previously each group name had to be unique within a regular expression.Sharing a group number also needs a fix in the SRE matching engine: outside of repeats it restores capture-group marks lazily (only rewinding the lastmark high-water index), which assumed each group number is written at a single place in the bytecode. Reused group numbers are now detected during code validation, and such patterns save and restore the full mark array on backtracking, as is already done inside repeats; other patterns are unaffected. The same flag also lets the possessive-quantifier handler request mark saving directly, replacing the placeholder repeat context previously installed for that purpose (gh-101955), so a possessive repeat no longer allocates a repeat context.
🤖 Generated with Claude Code