Repository navigation
Proposal: re.prefixmatch method (alias for re.match) #86519
Description
| BPO | 42353 |
|---|---|
| Nosy | @gpshead, @ezio-melotti, @serhiy-storchaka, @msuozzo |
| PRs |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = 'https://github.com/gpshead'
closed_at = None
created_at = <Date 2020-11-13.19:27:03.105>
labels = ['expert-regex', 'type-feature', 'library', '3.11']
title = 'Proposal: re.prefixmatch method (alias for re.match)'
updated_at = <Date 2022-02-05.08:57:42.604>
user = 'https://github.com/gpshead'bugs.python.org fields:
activity = <Date 2022-02-05.08:57:42.604>
actor = 'serhiy.storchaka'
assignee = 'gregory.p.smith'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)', 'Regular Expressions']
creation = <Date 2020-11-13.19:27:03.105>
creator = 'gregory.p.smith'
dependencies = []
files = []
hgrepos = []
issue_num = 42353
keywords = ['patch']
message_count = 6.0
messages = ['380928', '380975', '380984', '380996', '412554', '412564']
nosy_count = 5.0
nosy_names = ['gregory.p.smith', 'ezio.melotti', 'mrabarnett', 'serhiy.storchaka', 'matthew.suozzo']
pr_nums = ['31137']
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue42353'
versions = ['Python 3.11']
Activity
gpshead commentedon Nov 13, 2020
A well known anti-pattern in Python is use of re.match when you meant to use re.search.
re.fullmatchwas added in 3.4 via #60407 for similar reasons.re.prefixmatchwould be similar: we want the re.match behavior, but want the code to be obvious about its intent. This documents the implicit\A(or^when notre.MULTILINE) in the name.The goal would be to allow linters to ultimately flag
re.matchas the anti-pattern when in 3.12+ mode. Asking people to usere.prefixmatchorre.searchinstead.This would help avoid bugs where people mean
re.searchbut writere.matchand would ease the cognitive load at code review time by encouraging explicit code without detailed specific Pythonredomain knowledge on the reviewers part.The implementation is trivial.
This is not a decision to deprecate the widely used in 30 years worth of code's re.match name. That'd be painful and is unlikely to be worth doing.
Discussion in https://discuss.python.org/t/add-re-prefixmatch-deprecate-re-match/105927
serhiy-storchaka commentedon Nov 14, 2020
I seen a code which uses re.search() with anchor ^ instead of re.match(), but I never seen a code which uses re.match() instead of re.search(). It just won't work unless you add explicit ".*" or ".*?" at the start of the pattern, and it is a clear indication that re.match() matches the start of the string.
gpshead commentedon Nov 14, 2020
My point is that re.match is a common bug when people really want re.search.
re.prefixmatch makes it explicit and non-confusing and thus unlikely to be used wrong or misunderstood when read or reviewed.
The term "match" when talking about regular expressions is not normally meant to imply any anchoring as anchors can be expressed within the regex. Python is relatively unique in bothering to have different methods for a prefix match and an anywhere match. (We'd have been better off without a match method entirely, only having search - too late now)
msuozzo commentedon Nov 15, 2020
But think of when regexes are used for validating input. Getting it to "just work" may be over-permissive validation that only actually checks the beginning of the input. They're one missed test case away from a crash or, worse, a security issue.
This proposed name change would help make the function behavior obvious at the callsite. In the validator example, calling "prefixmatch" would stand out as wrong to even the most oblivious, documentation-averse user.
While I think better distinguishing the interfaces is a nice-to-have for usability, I think it has more absolute benefit to correctness. Again, confusion around the semantics of "match" were the motivation for adding "fullmatch" in the first place but that change only went so far to address the problem: It's still too easy to misuse the existing "match" interface and it's not realistic to remove it from the language. A new name would eliminate this class of error at a very low cost.
14 remaining items
gpshead commentedon Jul 18, 2022
There is a good case to be made that we as a project should provide automated code transformers with every Python release that can be used to migrate source code towards the preferred more modern thing when feasible (and encourage changes to be such that this is feasible). Past examples:
2to3did this where it could (limited) and ultimately is what lies behind themodernizetool which kept that torch lit and is more useful.But I wouldn't want to block this mere preferred more explicit name alias going in until such tooling to handle a decade later potential deprecation of the old name being available. They're separate requests.
tim-one commentedon Jan 30, 2026
+1 - adding "prefixmatch" is a clear win, with scant downside, provided "match" doesn't go away.
FURB167: change example to `re.search` with `^` anchor (#22984)
gh-86519: Add prefixmatch APIs to the re module (GH-31137)
gpshead commentedon Feb 16, 2026
merged, thanks for everyones reviews and discussions!
gpshead commentedon Feb 16, 2026
Updating
regexis tracked in mrabarnett/mrab-regex#601pythongh-86519: Add prefixmatch APIs to the re module (pythonGH-31137)
gh-86519: Update docs for `prefixmatch` (#148096)
pythongh-86519: Add prefixmatch APIs to the re module (pythonGH-31137)
pythongh-86519: Update docs for `prefixmatch` (python#148096)
FURB167: change example to `re.search` with `^` anchor (#22984)