gh-74453: Deprecate os.path.commonprefix by sethmlarson · Pull Request #144436 · python/cpython

sethmlarson · 2026-02-03T15:49:41Z

Follow-up from #144401, this PR moves to deprecate os.path.commonprefix() in favor of the correctly behaving os.path.commonpath() and the behavior-describing string.commonprefix().

I'm not sure if this is all I have to do to deprecate an API, if there is more documentation that needs to happen let me know.

Issue: Deprecate os.path.commonprefix #74453

📚 Documentation preview 📚: https://cpython-previews--144436.org.readthedocs.build/

picnixz

You need a What's New entry for that.

picnixz · 2026-02-03T16:20:49Z

+ import os
+ m = tuple(map(os.fspath, m))


I'm not really fond of this. string.commonprefix() should be specific to strings and should not care about pathlike objects.

Yeah, this is only done for backwards compatibility. I would be happy to get rid of it, but I figured that this would be not allowed considering we're doing a "rename", not a new API.

There is no backwards compatibility here. We create a new function in a module that is not related to filepaths at all. I do not consider this as a rename, I really consider this as a new API. Instead, I would keep the implementation of os.path.commonpath as is and add in a follow-up PR string.commonprefix which does not do the fspath computation. We then document that os.path.commonpath should be reimplemented as string.commonprefix(tuple(map(os.fspath, m))) if needed.

I believe this new string.commonprefix() should be a direct, one-to-one, drop-in replacement for the old os.path.commonprefix().
We're not doing anyone favours by changing the behaviour and making them [have to decide whether they need to] jump through extra hoops.
Chances are they should be using os.path.commonpath() instead, but if not, let them just replace the module name and keep the same old behaviour.
I doubt there's significant performance improvement from changing it either.

For me this isn't about performance, it's about semantics. string contains string-related utilities, not path-related ones. I am really opposed to having string.commonprefix being smart here. I know that we are not necessarily doing the user a favor but I don't want to have unrelated utilities in string. It is, for me, the wrong module for that.

hugovk

Please also list in Doc/deprecations/pending-removal-in-future.rst.

https://docs.python.org/dev/deprecations/index.html#pending-removal-in-future-versions

hugovk · 2026-02-03T17:20:37Z

+ import os
+ m = tuple(map(os.fspath, m))


I believe this new string.commonprefix() should be a direct, one-to-one, drop-in replacement for the old os.path.commonprefix().
We're not doing anyone favours by changing the behaviour and making them [have to decide whether they need to] jump through extra hoops.
Chances are they should be using os.path.commonpath() instead, but if not, let them just replace the module name and keep the same old behaviour.
I doubt there's significant performance improvement from changing it either.

Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com> Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>

sethmlarson · 2026-02-03T18:32:52Z

Alright, most recent two commits should address all review comments. I have preserved backwards compatibility in the drop-in replacement string.commonprefix().

Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>

picnixz

I am sorry, but I do not want string.commonprefix to be equivalent to os.path.commonprefix. Semantically it doesn't make sense to have an os-related utility in string.

In addition, we only talk about "strings" in the documentation. Having an implicit os.fspath conversion should be documented otherwise. If we want to mimic os.path.commonpath in the first place, I do not see why we can't just keep it but soft-deprecate it.

Note that commonprefix does not care about the fact that we are strings. It also works for any sequence, as long as the elements can be ordered (e.g., we can use commonprefix for list of lists):

>>>os.path.commonpath([[1], [1,3]])
[1]

Since we expose it in string, anyone using a non-string as the first argument will not be able to make it work (because we raise a TypeError in os.fspath). So I would expect a string-like object to be acceptable but because of os.fspath it wouldn't be. This would be contrary to what the string module stands for.

If we want a commonprefix utility, I would suggest adding one to itertools, and use the latter. I believe it makes more sense to have something related to commonprefix out there. Or for strings only, have it in difflib.

bedevere-app · 2026-02-03T19:48:15Z

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

And if you don't make the requested changes, you will be put in the comfy chair!

sethmlarson · 2026-02-03T21:48:16Z

Because I want to prioritize warning users about this function, I am okay with not providing a string.commonprefix() function and simply raising a DeprecationWarning in this PR. I want to avoid this warning getting delayed further, as has happened for the past ~30 years since the confusing behavior has been reported.

Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>

sethmlarson · 2026-02-03T23:08:57Z

@picnixz @hugovk I have removed string.commonprefix in 166c39d, I will happily revert or change this if there is a suggestion that should be completed in this PR.

(I have made the requested changes; please review again)

sethmlarson · 2026-02-04T15:46:33Z

I have made the requested changes; please review again

bedevere-app · 2026-02-04T15:46:40Z

Thanks for making the requested changes!

@hugovk, @picnixz: please review the changes made to this pull request.

vstinner

LGTM.

vstinner · 2026-02-05T10:20:04Z

 path_list = path_tail.split(sep) if path_tail else []
 # Work out how much of the filepath is shared by start and path.
- i = len(commonprefix([start_list, path_list]))
+ i = len(genericpath._commonprefix([start_list, path_list]))


Ah, this call is safe since it pass two lists of strings, and not two strings.

hugovk

Thanks!

picnixz · 2026-02-05T14:19:49Z

The question still remains about whether to expose string.commonprefix as something working on strings only (not paths), itertools.commonprefix (as working on any sequences) or the new seqtools module (I believe the discussion is stalled).

This would be a natural addition to that module, but that would also be a natural addition to more_itertools or another PyPI package dedicated to sequences utilities. OTOH, it'd still be possible to have it in itertools though supporting arbitrary iterables would make the implementation more complex.

OTOH, difflibcould be used as an alternative (I mean, difflib seems to work for any sequence, except when we want to format the change but otherwise the diff algorithm looks generic?)

vstinner · 2026-02-05T14:26:56Z

The question still remains about whether to expose string.commonprefix as something working on strings only (not paths), itertools.commonprefix (as working on any sequences) or the new seqtools module (I believe the discussion is stalled).

I'm not sure that we have to provide a replacement function. os.path.commonpath() should cover most usages.

hugovk · 2026-02-05T14:32:50Z

Please open a new issue or discussion if you'd like a new method. We decided not to provide a replacement here, so it can be considered independently.

picnixz · 2026-02-05T14:55:00Z

I personally don't think it's necessary to provide a pure replacement but I don't know whether Seth wants to

sethmlarson · 2026-02-05T15:00:47Z

I don't feel that we need an exact replacement. string.commonprefix() only operating on strings seems fine, but if it's not an exact replacement then it can happen outside this PR since it's unrelated then.

Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com> Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>

…on3.15 (#6102) python/cpython#144436 deprecates `os.path.commonprefix` in 3.15, causing a `DeprecationWarning` each time when using completion i copied the implementation of `commonprefix` (https://github.com/python/cpython/blob/957f9fe162398fceeaa9ddba8b40046b8a03176d/Lib/genericpath.py#L115-L129) and removed the unused `fspath`, as xonsh only uses `commonprefix` with `str | RichCompletion`, not `PathLike` i first thought about putting the function into the `xonsh.tools` module, but one of the places where `commonprefix` is used in `xonsh/completers/bash_completion.py`, which is intended to be usable as a standalone script, and adding an `import xonsh.tools` increased the startup time by a significant amount, so i decided to create a new helper module ## For community ⬇️ **Please click the 👍 reaction instead of leaving a `+1` or 👍 comment**

…gments (#9910) ## Description  SSIA. ## Checklist - [x] I have read the [contribution guide](https://docs.meltano.com/contribute/merge/) ### Was generative AI tooling used to co-author this PR?  - [ ] Yes (please specify the tool below)  ## Related Issues - pygments/pygments#3039 - python/cpython#74453 - python/cpython#144436 ## Summary by Sourcery Adjust test configuration to handle a new Python 3.15 deprecation warning from pygments and scope a Pyo3 compatibility flag to nox-managed environments. Build: - Add a pytest warning filter in pyproject.toml to ignore the pygments DeprecationWarning about os.path.commonprefix on Python 3.15. CI: - Remove the global PYO3_USE_ABI3_FORWARD_COMPATIBILITY environment variable from the GitHub Actions test workflow and rely on environment configuration within nox sessions instead. Tests: - Set PYO3_USE_ABI3_FORWARD_COMPATIBILITY within the nox _uv_sync session environment so that test environments retain the required Pyo3 ABI compatibility setting. Signed-off-by: Edgar Ramírez Mondragón <edgarrm358@gmail.com>

Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com> Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>

pythongh-74453: Deprecate os.path.commonprefix
f381a5e

sethmlarson requested review from StanFromIreland, hugovk, picnixz and vstinner February 3, 2026 15:49

bedevere-appBot added the awaiting review label Feb 3, 2026

bedevere-appBot mentioned this pull request Feb 3, 2026
Deprecate os.path.commonprefix #74453
Closed

sethmlarson mentioned this pull request Feb 3, 2026
gh-74453: Add stronger security warning to os.path.commonprefix #144401
Merged

picnixz reviewed Feb 3, 2026
View reviewed changes

hugovk reviewed Feb 3, 2026
View reviewed changes

sethmlarsonand others added 2 commits February 3, 2026 12:28

Address review comments
e8ca19c
Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com> Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>

Add entry to 'pending-removal-in-future'
cc320d1

sethmlarson requested review from hugovk and picnixz and removed request for picnixz February 3, 2026 18:33

hugovk approved these changes Feb 3, 2026
View reviewed changes

Comment threadDoc/deprecations/pending-removal-in-future.rst Outdated

bedevere-appBot added awaiting merge and removed awaiting review labels Feb 3, 2026

Address review comments
879d6ec
Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>

picnixz requested changes Feb 3, 2026
View reviewed changes

Comment threadDoc/library/string.rst Outdated

bedevere-appBot added awaiting changes and removed awaiting merge labels Feb 3, 2026

sethmlarsonand others added 2 commits February 3, 2026 21:56

Apply suggestions from code review
1f2086b
Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>

Remove 'string.commonprefix()' as an alternative
166c39d

sethmlarson force-pushed the deprecate-os-path-commonprefix branch from d4c0bb4 to 166c39dCompare February 3, 2026 23:06

bedevere-appBot added awaiting change review and removed awaiting changes labels Feb 4, 2026

bedevere-appBot requested a review from hugovk February 4, 2026 15:46

vstinner approved these changes Feb 5, 2026
View reviewed changes

bedevere-appBot added awaiting merge and removed awaiting change review labels Feb 5, 2026

picnixz approved these changes Feb 5, 2026
View reviewed changes

hugovk approved these changes Feb 5, 2026
View reviewed changes

hugovk merged commit 957f9fe into python:mainFeb 5, 2026
52 of 55 checks passed

bedevere-appBot removed the awaiting merge label Feb 5, 2026

sethmlarson deleted the deprecate-os-path-commonprefix branch February 5, 2026 20:37

sethmlarson mentioned this pull request Feb 5, 2026
Rule to advise os.path.commonprefix is wrong and you should use os.path.commonpathastral-sh/ruff#22981
Closed

This was referenced Feb 17, 2026
fix(completion): Fix os.path.commonprefix deprecation warning in python3.15 xonsh/xonsh#6102
Merged
fix(regexopt): Fix os.path.commonprefix deprecation warning in python3.15 pygments/pygments#3040
Merged

edgarrmondragon mentioned this pull request Feb 21, 2026
Fixes workspace member detection to properly handle shared path prefixes pypa/hatch#2187
Merged

This was referenced Feb 27, 2026
Fix os.path.commonprefix deprecation python/pymanager#280
Merged
Fix os.path.commonprefix deprecation numpy/numpy#30898
Merged

edgarrmondragon mentioned this pull request Mar 20, 2026
test: Handle Python 3.15 warning coming from transitive dependency pygments meltano/meltano#9910
Merged
2 tasks

notatallshaw mentioned this pull request Apr 15, 2026
pip 26.0.1 raises warnings with Python 3.15.0a8 pypa/pip#13922
Closed
1 task

Uh oh!

Uh oh!

Conversation

sethmlarson commented Feb 3, 2026• edited by github-actions BotLoading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

picnixz left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

picnixzFeb 3, 2026

Choose a reason for hiding this comment

Uh oh!

sethmlarsonFeb 3, 2026

Choose a reason for hiding this comment

Uh oh!

picnixzFeb 3, 2026

Choose a reason for hiding this comment

Uh oh!

hugovkFeb 3, 2026

Choose a reason for hiding this comment

Uh oh!

picnixzFeb 3, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

hugovk left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

hugovkFeb 3, 2026

Choose a reason for hiding this comment

Uh oh!

sethmlarson commented Feb 3, 2026

Uh oh!

Uh oh!

picnixz left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

bedevere-appBot commented Feb 3, 2026

Uh oh!

sethmlarson commented Feb 3, 2026

Uh oh!

sethmlarson commented Feb 3, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

sethmlarson commented Feb 4, 2026

Uh oh!

bedevere-appBot commented Feb 4, 2026

Uh oh!

vstinner left a comment

Choose a reason for hiding this comment

Uh oh!

vstinnerFeb 5, 2026

Choose a reason for hiding this comment

Uh oh!

hugovk left a comment

Choose a reason for hiding this comment

Uh oh!

picnixz commented Feb 5, 2026

Uh oh!

vstinner commented Feb 5, 2026

Uh oh!

hugovk commented Feb 5, 2026

Uh oh!

picnixz commented Feb 5, 2026

Uh oh!

sethmlarson commented Feb 5, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

sethmlarson commented Feb 3, 2026•
edited by github-actions Bot
Loading

picnixz left a comment •
edited
Loading

sethmlarson commented Feb 3, 2026•
edited
Loading

sethmlarson commented Feb 5, 2026•
edited
Loading