Python 3.15 soft-deprecates re.match and adds re.prefixmatch as a clearer alias

Hugo van Kemenade, the Python 3.15 release manager, posted on 10 September that re.match() is being soft-deprecated in Python 3.15 and that re.prefixmatch() is joining the standard library as a new alias for the same function. Simon Willison flagged the post on his weblog the next day. The two names call the same code; the point is that one of them tells the reader what the code does.

The 30-year gotcha

re.match() has been in the standard library since Python 1.5 and, in van Kemenade's words, "has been used in code for over 30 years". It only matches at the beginning of the string, which is what surprises new readers: re.search() matches anywhere, re.fullmatch() anchors both ends, and re.match() anchors only the start. The name gives no clue that the start of the string is special. Van Kemenade puts it plainly: "Anyone reading the name prefixmatch() is likely to understand the intended semantics. When reading match() there remains a seed of doubt about the intended behavior to anyone not already familiar with this old Python gotcha."

Soft deprecation, not removal

PEP 387 defines soft deprecation for exactly this case. Van Kemenade quotes it: "A soft deprecation can be used when using an API which should no longer be used to write new code, but it remains safe to continue using it in existing code," and "A soft deprecation does not imply future removal of the API, nor does it issue a warning." So re.match() stays in the standard library, stays supported, and stays quiet at runtime. The change is a documentation change with a new alias behind it. Existing programs do not need to be edited to keep working on Python 3.15, and code that has to run against older Python versions should keep using re.match().

The practical rule van Kemenade sets out is: "code supporting older versions of Python should continue to use match(), while new code should prefer prefixmatch()." For a team writing new Python today on 3.15, that is a one-line habit change with no cost. For a codebase that already uses re.match(), the answer is to leave it alone until the file is being edited anyway, and to prefer the new name when writing new callers.

The consequence is small on any single call and adds up on a large codebase. A reader who lands on re.prefixmatch(pattern, text) does not stop to check whether the function anchors the start, the end, or nothing at all, so a whole class of quiet regex bugs, the ones where the author reached for re.match() when re.fullmatch() or re.search() was the right call, gets a bit less likely at the point somebody else reads the code. That is the value of a name that describes behaviour, and it is why standard-library churn on cosmetic grounds is usually a bad idea and this one is not.

Source

Hugo van Kemenade's Soft-deprecating re.match(), pointed to by Simon Willison's linkblog note on 11 September. The soft-deprecation policy sits in PEP 387.