Python 3.15、re.match()をre.prefixmatchへソフト非推奨に
Python 3.15は、新しいre.prefixmatch()を推奨し、re.match()をソフトデプリケーション(緩やかな非推奨)にします。壊れるものはなく、警告も出ず、削除も予定されていません。
3 分で読めます

数字で見る
- Python version adding re.prefixmatch()
- 3.15
- runtime warnings a soft deprecation emits
- 0
Python 3.15はre.prefixmatch()という関数を追加し、その代わりに30年前からあるre.match()をソフト非推奨(soft deprecated)と位置づけます。この二つはまったく同じ動作をします。変更の狙いは名前にあります。matchという語は、この関数が存在してきた期間ずっと、Pythonでは誤った意味を持っていたからです。
Python 3.15のreモジュールのドキュメントは、その理由を直接述べています。新しい名前のほうが「より明示的に説明的」であり、開発者は「意図をより良く表すために」それを使うべきだ、というものです。他の多くの言語では、matchはPythonが一貫してsearch()と呼んできた動作を指す、ともドキュメントは指摘しています。
名前の問題
Pythonのre.match()は文字列の先頭しか見ません。位置0に固定され、そこで止まります。re.search()は文字列全体を走査し、どの位置にあってもパターンを探します。
他の多くの言語は逆です。それらの「match」はPythonの「search」にあたります。JavaScript、Ruby、Goから来た開発者はre.match()を読み、どこにあってもパターンを見つけると当然のように考えます。実際にはそうなりません。そして生じるバグは静かです。処理すべき入力に対して、コードが単にNoneを返すだけだからです。
re.match("world", "hello world") # None - 先頭に固定されている
re.prefixmatch("world", "hello world") # None - 同じ関数、より明確な名前
re.search("world", "hello world") # 一致する
Hugo van Kemenade氏は2026年9月10日に公開したブログ記事でこの主張を展開し、Zen of Pythonを引用しました。「明示は暗黙に勝る。prefixmatch()という名前を読んだ人は、意図された意味を理解できる可能性が高い」。
モジュールレベルの関数と、コンパイル済みパターンのメソッドの両方が新しい名前を得ます。3.15ではre.prefixmatch()に加えてre.Pattern.prefixmatch()が追加されます。
「ソフト非推奨」が実際に意味すること
ソフトデプリケーションは、Pythonの後方互換性ポリシーであるPEP 387で定められた具体的な手続きです。通常の非推奨よりはるかに弱いもので、その違いは古いコードを保守する人にとって重要です。
| ソフト非推奨 | 通常の非推奨 | |
|---|---|---|
| 実行時の警告 | なし | DeprecationWarning |
| 削除の予定 | なし | あり、バージョンを指定 |
| ドキュメントとテストの維持 | 維持される | 削除まで維持される |
| 新機能の追加 | なし | なし |
PEP 387はこれを「新しいコードを書くのにはもう使うべきではないが、既存のコードで使い続けるのは安全なAPIを使うこと」と定義しています。また、ソフト非推奨は「警告を出さない。ドキュメントで触れられるだけである」とも明記しています。
つまりre.match()は動き続けます。削除は予定されていません。3.15へ移行してもテストスイートが警告を出し始めることはなく、python -W errorで失敗することもありません。
四つのうちどれを使うか
reモジュールは、パターンを文字列に適用する方法を四つ提供するようになりました。違いは、パターンがどこにあってよいかだけです。
| 関数 | 一致する範囲 | 追加されたバージョン |
|---|---|---|
re.prefixmatch() | 先頭のみ | 3.15 |
re.match() | 先頭のみ、ソフト非推奨 | 1.5 |
re.search() | 文字列内のどこでも | 1.5 |
re.fullmatch() | 文字列全体、先頭から末尾まで | 3.4 |
開発者にとっての意味
急いで何かをする必要はありません。これは、移行を求めず、期限も設けず、コードを壊さない珍しいAPI変更です。
3.15以降の新しいコードではre.prefixmatch()と書いてください。その名前は、次に読む人にその呼び出しが実際に何をするのかを伝えます。それがこの変更の目的そのものです。
既存のコードで役に立つのは、一括置換ではありません。点検です。コードベースにあるre.match()の呼び出しはどれも、書いた人がre.search()のつもりだった可能性のある箇所です。パターンが先頭にある入力しかテストに渡していなければ、テストはそれを捕まえられません。それらは3.15より前から存在する本物のバグであり、簡単なgrepならどんなツールより速く候補を見つけられます。
ただし、ライブラリでいきなりre.prefixmatch()に移るのは慎重に。これを呼ぶと、パッケージがPython 3.15以降を必要とするようになります。サポートする最低バージョンが追いつくまでは、re.match()のほうが版をまたいで使える書き方です。大規模なコードベースは何年もその差と付き合います。EVE Onlineの開発陣がPython 3への移行を始めたのも、バージョンが分かれてからずいぶん後のことでした。
より大きな意味合いにも触れておく価値があります。Pythonのコアチームは、誰にも1行の変更も強いることなく、古いAPIが正しく読めるようにするためだけに、新しい名前とドキュメントの注記を費やす用意があるということです。これは安上がりな片付け方です。Pythonがこれを重ねるほど、次の世代のPython開発者がデバッグすべき静かなNoneは減っていきます。
出典
- Soft-deprecating re.match() - hugovk.dev
- re - Regular expression operations (Python 3.15) - Python documentation
- What's New In Python 3.15 - Python documentation
- PEP 387 - Backwards Compatibility Policy - Python Enhancement Proposals
関連記事

HTTP QUERYにはRFC 10008があるが、実装はほとんどない
RFC 10008は2026年6月、HTTPにQUERY(クエリ)メソッドを加えました。GETのように安全で冪等、POSTのようにリクエストボディを持ちます。それを実装しているものは、まだほとんどありません。

EVE Onlineが240万行のPython 2をPython 3へ移行開始
CCP Gamesによれば、EVEの240万行のうち95.9%はすでに両方のPythonバージョンで構文解析できる。残る3,300行が移行を止めている。

MojoがApache 2.0でオープンソース化、コントリビューションは非公開のまま
ModularはMojo 1.0のリリースから1週間後、MojoコンパイラとツールをApache 2.0で公開した。ただし外部からのコンパイラへのコントリビューションは2026年後半まで受け付けない。