[issue30267] Deprecate os.path.commonprefix

Serhiy Storchaka added the comment: For now, there are three uses of commonprefix() in the stdlib: 1. In urllib.request it causes a security issue (see issue46756). commonpath() or just str.startswith() should be used instead. 2. In lib2to3.main. The code contains a workaround around

[issue30267] Deprecate os.path.commonprefix

Raymond Hettinger added the comment: The ``os.path.commonprefix`` function has been around for a very long time. Deprecating it will just cause unnecessary pain for users and make it harder to upgrade to Python 3. The function isn't broken, the only issue here is that a new function was

[issue30267] Deprecate os.path.commonprefix

Brett Cannon added the comment: I agree with Serhiy that it might be time to create a seqtools module. -- nosy: +brett.cannon ___ Python tracker ___

[issue30267] Deprecate os.path.commonprefix

Serhiy Storchaka added the comment: We shouldn't deprecate a function until add an alternative. There is a working alternative for paths, but commonprefix() is used in the wild for non-paths (for example in unittest.util). The problem is that there is no right place for this function. The

[issue30267] Deprecate os.path.commonprefix

STINNER Victor added the comment: Ned Batchelder wrote an article about this function in 2010 :-) https://nedbatchelder.com/blog/201003/whats_the_point_of_ospathcommonprefix.html """ The docs helpfully include the warning: Note that this may return invalid paths because it works a

[issue30267] Deprecate os.path.commonprefix

New submission from ProgVal: The function os.path.commonprefix computes the longest prefix of strings (any iterable, actually), regardless of their meaning as paths. I do not see any reason to use this function for paths, and keeping it in the os.path module makes it prone to be confused with