gh-86519: Add prefixmatch APIs to the re module

[gpshead]

Adds prefixmatch APIs to the re module as an alternate name for our long existing match APIs to help alleviate a common Python confusion for those coming from other languages regular expression libraries.

These alleviate common confusion around what "match" means as Python is different than other popular languages regex libraries in our use of the term as an API name. The original match names are NOT being deprecated. Source tooling like linters, IDEs, and LLMs could suggest using prefixmatch instead of match to improve code health and reduce cognitive burden of understanding the intent of code when configured for a modern minimum Python version.

See the documentation changes within this PR for a better description.

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

Documentation Preview: https://cpython-previews--31137.org.readthedocs.build/en/31137/

[python-cla-bot]

All commit authors signed the Contributor License Agreement.

[hauntsaninja]

Great, thank you for making this happen!

[picnixz]

Did we actually reached a consensus on DPO for that feature to be merged? I thought there were some issues, especially with the fact that regex needs to be updated to be with parity.

[hugovk]

Did we actually reached a consensus on DPO for that feature to be merged?

Yes, I think the 24 hearts on Greg's https://discuss.python.org/t/add-re-prefixmatch-deprecate-re-match/105927/20 is a pretty good sign.

The only other posts with double-digit hearts are also in support: the OP (10), a docs suggestion from Tim (14), a name suggestion (startswith) from Marc-André (11).

I thought there were some issues, especially with the fact that regex needs to be updated to be with parity.

Whatever the third-party regex package does or doesn't do, shouldn't hold us back. They say "This regex implementation is backwards-compatible with the standard ‘re’ module, but offers additional functionality", so it doesn't sound like it'll be a problem for them to do the same thing.

[hugovk]

Thanks!

Non-blocking docs suggestion:

Use prefixmatch pretty much throughout, except to mention match is the alias (plus version changed etc.), which you've mostly already done here.

We can also update other places like the regex HOWTO to prefer the new name, but this can also be in a followup.

Bike shed colour:

I'm fine with either prefixmatch and startswith.

Pro for prefixmatch: it keeps the "match" part, which might help remind people when they see match: "oh, wait, is this the lopsided prefixmatch or fullmatch? I'd better double check the docs and use one of those descriptive names or instead search with explicit anchors."

Soft deprecation:

We're discouraging in docs and not planning on removing. Sounds like soft deprecation. I'd be fine with soft deprecating too, but that could also be another discussion once this is done (if anyone has energy for that!).

[gpshead]

Bike shed colour:
I'm fine with either prefixmatch and startswith.
Pro for prefixmatch: it keeps the "match" part, which might help remind people

I'm similarly inclined to stick with prefixmatch. It ties in with match wording elsewhere and avoids confusion w.r.t. the str/bytes methods of the same startswith name.

lots of what look like good comments on the docs here and thoughts on how to document this to digest from the discuss thread. i'll work on getting the doc edits in and see if it looks like it needs more review after that.