Skip to content

Proposal: re.prefixmatch method (alias for re.match) #86519

Closed
Closed
Proposal: re.prefixmatch method (alias for re.match)#86519
Assignees
gpshead
Labels
stdlibStandard Library Python modules in the Lib/ directorytopic-regextype-featureA feature request or enhancement

Description

@gpshead
gpshead
opened on Nov 13, 2020
BPO 42353
Nosy @gpshead, @ezio-melotti, @serhiy-storchaka, @msuozzo
PRs
  • gh-86519: Add prefixmatch APIs to the re module #31137
    		•

    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']

    Linked PRs

    Activity

    1. gpshead commented on Nov 13, 2020

      @gpshead
      gpshead
      on Nov 13, 2020
      MemberAuthor

      A well known anti-pattern in Python is use of re.match when you meant to use re.search.

      re.fullmatch was added in 3.4 via #60407 for similar reasons.

      re.prefixmatch would 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 not re.MULTILINE) in the name.

      The goal would be to allow linters to ultimately flag re.match as the anti-pattern when in 3.12+ mode. Asking people to use re.prefixmatch or re.search instead.

      This would help avoid bugs where people mean re.search but write re.match and would ease the cognitive load at code review time by encouraging explicit code without detailed specific Python re domain 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

    2. gpshead
      added
      3.10 (EOL)end of life
      stdlibStandard Library Python modules in the Lib/ directory
      type-featureA feature request or enhancement
      on Nov 13, 2020
    3. tirkarthi
      added
      topic-regex
      on Nov 14, 2020

    4. serhiy-storchaka commented on Nov 14, 2020

      @serhiy-storchaka
      serhiy-storchaka
      on Nov 14, 2020
      Member

      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.

    5. gpshead commented on Nov 14, 2020

      @gpshead
      gpshead
      on Nov 14, 2020
      MemberAuthor

      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)

    6. msuozzo commented on Nov 15, 2020

      @msuozzo
      msuozzomannequin
      on Nov 15, 2020
      Mannequin

      It just won't work unless you add explicit ".*" or ".*?" at the start of the pattern

      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.

      My point is that re.match is a common bug when people really want re.search.

      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.

    7. gpshead
      added
      3.11only security fixes
      and removed
      3.10 (EOL)end of life
      on Feb 4, 2022
    8. gpshead
      self-assigned this
      on Feb 4, 2022

    9. 14 remaining items

    10. gpshead commented on Jul 18, 2022

      @gpshead
      gpshead
      on Jul 18, 2022
      MemberAuthor

      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: 2to3 did this where it could (limited) and ultimately is what lies behind the modernize tool 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.

    11. erlend-aasland
      added
      3.13only security fixes
      and removed
      3.12only security fixes
      on Jan 5, 2024
    12. picnixz
      removed
      3.13only security fixes
      on Apr 18, 2025

    13. tim-one commented on Jan 30, 2026

      @tim-one
      tim-one
      on Jan 30, 2026
      Member

      +1 - adding "prefixmatch" is a clear win, with scant downside, provided "match" doesn't go away.

    14. ntBre
      added a commit that references this issue on Jan 30, 2026

      FURB167: change example to `re.search` with `^` anchor (#22984)

      38d4f49
    15. gpshead
      added a commit that references this issue on Feb 16, 2026

      gh-86519: Add prefixmatch APIs to the re module (GH-31137)

      300de1e

    16. gpshead commented on Feb 16, 2026

      @gpshead
      gpshead
      on Feb 16, 2026
      MemberAuthor

      merged, thanks for everyones reviews and discussions!

    17. gpshead
      closed this as completedon Feb 16, 2026

    18. gpshead commented on Feb 16, 2026

      @gpshead
      gpshead
      on Feb 16, 2026
      MemberAuthor

      Updating regex is tracked in mrabarnett/mrab-regex#601

    19. brijkapadia
      added a commit that references this issue on Feb 28, 2026

      pythongh-86519: Add prefixmatch APIs to the re module (pythonGH-31137)

      22df6fe
    20. hugovk
      added a commit that references this issue on Apr 14, 2026

      gh-86519: Update docs for `prefixmatch` (#148096)

      bdb0b36
    21. ljfp
      added 2 commits that reference this issue on Apr 25, 2026

      pythongh-86519: Add prefixmatch APIs to the re module (pythonGH-31137)

      a8c1cbc

      pythongh-86519: Update docs for `prefixmatch` (python#148096)

      67fecb1
    22. KotlinIsland
      added a commit that references this issue on May 1, 2026

      FURB167: change example to `re.search` with `^` anchor (#22984)

      730e469
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

    Metadata

    Metadata

    Assignees

    Labels

    stdlibStandard Library Python modules in the Lib/ directorytopic-regextype-featureA feature request or enhancement

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions