Python 3.15 déprécie en douceur re.match() au profit de re.prefixmatch
Python 3.15 déprécie en douceur re.match() au profit du nouveau re.prefixmatch(). Rien ne casse, rien n'avertit, et aucune suppression n'est programmée.
3 min de lecture

En chiffres
- Python version adding re.prefixmatch()
- 3.15
- runtime warnings a soft deprecation emits
- 0
Python 3.15 ajoute une fonction nommée re.prefixmatch() et marque à sa place re.match(), vieille de 30 ans, comme dépréciée en douceur. Les deux font exactement la même chose. Le changement porte sur le nom, car match désigne la mauvaise chose en Python depuis aussi longtemps que la fonction existe.
La documentation de Python 3.15 pour le module re énonce directement la raison. Le nouveau nom est « plus explicitement descriptif », dit-elle, et les développeurs devraient l'employer « pour mieux exprimer leur intention ». Dans la plupart des autres langages, note la documentation, match désigne le comportement que Python a toujours appelé search().
Le problème de nom
Le re.match() de Python ne regarde que le début d'une chaîne. Il s'ancre à la position zéro et s'arrête là. re.search() parcourt toute la chaîne à la recherche du motif, où qu'il se trouve.
La plupart des autres langages font l'inverse. Leur « match » est le « search » de Python. Un développeur venant de JavaScript, Ruby ou Go lit re.match() et s'attend raisonnablement à ce qu'il trouve le motif n'importe où. Ce n'est pas le cas, et le bogue qui suit est silencieux : le code renvoie simplement None sur une entrée qu'il aurait dû traiter.
re.match("world", "hello world") # None - ancré au début
re.prefixmatch("world", "hello world") # None - même fonction, nom plus clair
re.search("world", "hello world") # correspond
Hugo van Kemenade a exposé l'argument dans un billet de blog publié le 10 septembre 2026, en citant le Zen of Python : « Explicite vaut mieux qu'implicite. Quiconque lit le nom prefixmatch() comprendra probablement la sémantique visée. »
La fonction au niveau du module et la méthode des motifs compilés reçoivent toutes deux le nouveau nom. re.Pattern.prefixmatch() rejoint re.prefixmatch() dans la 3.15.
Ce que « déprécié en douceur » signifie vraiment
La dépréciation en douceur est un processus précis défini dans PEP 387, la politique de compatibilité ascendante de Python. Elle est bien plus faible qu'une dépréciation normale, et la différence compte pour quiconque maintient du code ancien.
| Dépréciation en douceur | Dépréciation normale | |
|---|---|---|
| Avertissement à l'exécution | Aucun | DeprecationWarning |
| Suppression programmée | Non | Oui, dans une version nommée |
| Reste documentée et testée | Oui | Oui, jusqu'à la suppression |
| Reçoit de nouvelles fonctionnalités | Non | Non |
PEP 387 la définit comme « l'utilisation d'une API qui ne devrait plus servir à écrire du nouveau code, mais qu'il reste sûr de continuer à utiliser dans du code existant ». Il précise aussi clairement qu'une dépréciation en douceur « n'émet pas d'avertissement : elle est seulement mentionnée dans la documentation ».
re.match() continue donc de fonctionner. Sa suppression n'est pas programmée. Votre suite de tests ne se mettra pas à afficher des avertissements en passant à la 3.15, et python -W error n'échouera pas dessus.
Laquelle des quatre choisir
Le module re propose désormais quatre façons d'appliquer un motif à une chaîne. Elles ne diffèrent que par l'endroit où le motif a le droit de se trouver.
| Fonction | Correspond | Ajoutée en |
|---|---|---|
re.prefixmatch() | Au début seulement | 3.15 |
re.match() | Au début seulement, dépréciée en douceur | 1.5 |
re.search() | N'importe où dans la chaîne | 1.5 |
re.fullmatch() | La chaîne entière, du début à la fin | 3.4 |
Ce que cela signifie pour les développeurs
Rien d'urgent à faire. C'est le rare changement d'API qui ne demande aucune migration, ne fixe aucune échéance et ne casse aucun code.
Pour du nouveau code en 3.15 ou plus récent, écrivez re.prefixmatch(). Le nom dit au prochain lecteur ce que l'appel fait réellement, et c'est tout l'objet du changement.
Pour le code existant, l'exercice utile n'est pas un rechercher-remplacer. C'est un audit. Chaque appel à re.match() dans votre base de code est un endroit où quelqu'un a peut-être voulu écrire re.search(). Les tests ne le détecteraient pas s'ils n'ont jamais passé que des entrées où le motif se trouvait au début. Ce sont de vrais bogues antérieurs à la 3.15, et un simple grep trouvera les candidats plus vite que n'importe quel outil.
Méfiez-vous toutefois de passer directement à re.prefixmatch() dans une bibliothèque. L'appeler impose à votre paquet Python 3.15 ou plus récent, et re.match() reste l'écriture portable entre versions tant que votre version minimale prise en charge n'a pas rattrapé son retard. Les grandes bases de code vivent des années avec cet écart ; les développeurs d'EVE Online ont entamé leur migration vers Python 3 bien après la séparation des versions.
Le signal plus large mérite d'être noté. L'équipe centrale de Python accepte de dépenser un nouveau nom et une note de documentation uniquement pour qu'une vieille API se lise correctement, sans forcer quiconque à changer une ligne. C'est un nettoyage peu coûteux, et plus Python en fait, moins la prochaine génération de développeurs Python aura de retours None silencieux à déboguer.
Sources
- 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
Articles liés

HTTP QUERY a sa RFC, mais presque aucune implémentation
La RFC 10008 a donné à HTTP une méthode QUERY en juin 2026 : sûre et idempotente comme GET, avec un corps de requête comme POST. Presque rien ne l'implémente encore.

EVE Online commence à migrer 2,4 millions de lignes de Python 2 vers Python 3
CCP Games indique que 95,9 % des 2,4 millions de lignes d'EVE s'analysent déjà sous les deux versions de Python. Les 3 300 lignes restantes bloquent la migration.

Mojo passe en open source sous Apache 2.0, les contributions restent fermées
Modular a publié en open source le compilateur et l'outillage de Mojo sous Apache 2.0, une semaine après Mojo 1.0 - mais n'acceptera pas de contributions externes au compilateur avant fin 2026.