Not planned
Description
Bug report
Bug description:
>>> import posixpath
>>> posixpath.commonpath(["//foo/bar", "//foo/baz"])
'/foo'
Expected: //foo
with precisely two leading slashes, see: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_13
This can be quite easily solved using posixpath.splitroot
, see the PR.
CPython versions tested on:
CPython main branch
Operating systems tested on:
macOS
Activity
//
forposixpath.commonpath
#117202[-]`posixpath.commonpath` doesn't handle leading `//` properly[/-][+]Handle leading `//` for `posixpath.commonpath`[/+]//
forposixpath.commonpath
#117334os
#117361serhiy-storchaka commentedon Apr 4, 2024
For reference, the original issue that introduced
commonpath()
is bpo-10395/gh-54604.And its behavior was discussed at https://mail.python.org/archives/list/python-ideas@python.org/thread/VHQTSU4ERTH262OPVZ6SEO2EYCFQF56G/.
erlend-aasland commentedon Apr 4, 2024
cc. @ronaldoussoren
nineteendo commentedon Apr 5, 2024
This is the reason I don't like the current implementation:
Output:
path1 is not a parent of path2
.erlend-aasland commentedon Apr 5, 2024
If anything, this looks to me like a
commonpath
documentation issue.Moreover, if I were to write such a test, I would normalise
tail1
before comparing it, or more probable: use a higher level API.nineteendo commentedon Apr 5, 2024
If that's the case, that's fine by me, but that should be confirmed by @ronaldoussoren.
The thing is: the paths are already normalised here, but that won't replace precisely 2 leading slashes. Which is intended behaviour.
erlend-aasland commentedon Apr 5, 2024
splitdrive
does not normalise the paths, if that is what you imply.nineteendo commentedon Apr 5, 2024
No, the paths I'm passing to
splitdrive()
are already normalised (I addedabspath()
to make that clearer), but I would still need to applycommonpath()
to the tail to make the comparison work. I shouldn't have to do that.erlend-aasland commentedon Apr 5, 2024
Well, it is still a backwards-incompatible change.
nineteendo commentedon Apr 5, 2024
Anyway, whether this will be accepted depends on whether this is intentional behaviour or not:
os.path.isabs()
was changed to handle paths correctly starting with exactly one (back)slash on Windows.ronaldoussoren commentedon Apr 5, 2024
IMHO we should consider dropping special handling for '//' at the start of a path for our path manipulation APIs. I cannot recall a Unix where '//foo' is different from '/foo', but it is an awfully long time that I've used anything other than Linux and macOS.
The Open Group documents that '//foo' may be special ("may be treated in an implementation defined way"), but AFAIK commonly used UNIX-y systems don't use this possibility.
Because most systems don't treat '//foo' specially we shouldn't change the behaviour of
os.path.commonpath
as this will only lead to confusing users and might have a security impact for code that expects the current behaviour.8 remaining items