os.path.relpath() assumes '//' root is equivalent to '/'

[iynehz]

Bug report

pathlib's Path.relative_to() and os.path.relpath(), the two have different behavior: On Linux os.path.relpath() understands double-slash in path is same as single slash, but Path.relative_to() does not.

For example,

import os
os.path.relpath('//foo/bar', '/foo')                 # results 'bar'

from pathlib import Path
pathlib.PosixPath('//foo/bar').relative_to('/foo')   # raises ValueError

pytest issue pytest-dev/pytest#9894 relates to this.

Your environment

• CPython versions tested on: 3.9.2
• Operating system and architecture: Debian Bullseye

Linked PRs

• GH-92737: Corrected posixpath behaviour to not assume '//' is equivalent to '/'. #103798

[eryksun]

Cross-platform POSIX applications should not assume that "//foo" is the same as "/foo". A path that begins with two slashes is reserved in POSIX for use by implementations. Linux handles "//foo" the same as "/foo". Cygwin, on the other hand, supports UNC paths such as "//server/share".

A strict=False parameter could be added to posixpath.relpath() in order to force POSIX-ly correct behavior. For pathlib.PosixPath.relative_to() the default could be strict=True.

[achhina]

@eryksun Would you still think adding a strict parameter be a good way to move forward with this? If so, I'd like to attempt to implement that.

[barneygale]

I'd argue that posixpath.relpath() should simply be fixed and that there's no need for a new parameter. I recall GvR saying he cringes a little every time we add a new parameter that users need to set to get correct behaviour.

The implementation should call splitroot() and raise if the roots are different, just like ntpath.relpath() does.

[achhina]

@barneygale Would in this case fixing posixpath.relpath mean no longer assuming paths beginning // are the same as /? If that's the case, would we need to introduce a deprecation cycle for users who are relying on the current assumption?

[barneygale]

would we need to introduce a deprecation cycle for users who are relying on the current assumption?

It's a bugfix, so not necessarily. Quoth PEP 387:

This policy applies to all public APIs. These include: [...] Given a set of arguments, the return value, side effects, and raised exceptions of a function. This does not preclude changes from reasonable bug fixes.

But if we think fixing it will cause sadness, we could skip backporting or perhaps hide it behind an argument as Eryk suggests.