pathlib method relative_to doesnt work with // in paths

@eryksun

BPO	47161
Nosy	@eryksun, @barneygale, @arhadthedev, @John15321
PRs	gh-91317: Document that Path does not collapse initial `//` #32193

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2022-03-30.11:01:52.097>
labels = ['3.8', 'type-bug', 'library']
title = 'pathlib method relative_to doesnt work with // in paths'
updated_at = <Date 2022-04-01.15:38:13.214>
user = 'https://github.com/John15321'

bugs.python.org fields:

activity = <Date 2022-04-01.15:38:13.214>
actor = 'barneygale'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2022-03-30.11:01:52.097>
creator = 'John15321'
dependencies = []
files = []
hgrepos = []
issue_num = 47161
keywords = ['patch']
message_count = 8.0
messages = ['416336', '416342', '416348', '416351', '416352', '416355', '416356', '416489']
nosy_count = 4.0
nosy_names = ['eryksun', 'barneygale', 'arhadthedev', 'John15321']
pr_nums = ['32193']
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue47161'
versions = ['Python 3.8']

The // path should be equivalent to /, and in some ways, it does behave like that in pathlib. But in the relative_to method on a Path object, it does not work
This is causing our CI pipeline to fail. In the documentation here you can see // being properly processed:

https://docs.python.org/3/library/pathlib.html

In [10]: x=Path("/Library/Video") ; x.relative_to(Path("/"))
Out[10]: PosixPath('Library/Video')

In [11]: x=Path("//Library/Video") ; x.relative_to(Path("/"))
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
Input In [11], in <cell line: 1>()
----> 1 x=Path("//Library/Video") ; x.relative_to(Path("/"))

File ~/.pyenv/versions/3.8.13/lib/python3.8/pathlib.py:908, in PurePath.relative_to(self, *other)
    906 if (root or drv) if n == 0 else cf(abs_parts[:n]) != cf(to_abs_parts):
    907     formatted = self._format_parsed_parts(to_drv, to_root, to_parts)
--> 908     raise ValueError("{!r} does not start with {!r}"
    909                      .format(str(self), str(formatted)))
    910 return self._from_parsed_parts('', root if n == 1 else '',
    911                                abs_parts[n:])

ValueError: '//Library/Video' does not start with '/'

I started to investigate and found that a double slash in the beginning cancels any parsing of a path:

    >>> Path("//Library/Video")._parts
    ['\\\\Library\\Video\\']

vs

    >>> Path("/Library/Video")._parts
    ['\\', 'Library', 'Video']

Investigating further.

As I found out, any path starting with two double slashes is treated as an UNC (network) path:

vvvvvvvvvvvvvvvvvvvv root
\\machine\mountpoint\directory\etc\...
           directory ^^^^^^^^^^^^^^^^^

So "/Library/Video" and "/" are directories mounted on your machine while "//Library/Video" is a computer named "Library" with a share named "Video".

However, an error message in Python 3.8 (as a file path suggests) is misleading. In 3.11 it was changed to "'\\Library\Video\' is not in the subpath of '\' OR one path is relative and the other is absolute."

Also, the error message cannot be fixed because for 3.8 only security fixes are accepted since May 2021. For 3.9 and later, the message is already corrected.

But shouldn't it just work with // as a /? It seems like this is the behavior elsewhere. Sure I get that it cannot be done for 3.8. But the new error message implies that either // is not a subpath of / which it is, or that one is relative and the other is absolute, which is also false because both are absolutes

But shouldn't it just work with // as a /? It seems like this is the behavior elsewhere.

It works elsewhere because empty directory names are impossible so can be dropped. But if // is placed in the beginning, it gets a special meaning that totally changes the whole path so its plain replacement would give a totally wrong one.

Roughly speaking, "//Library/Video" is /Video on a computer named Library.

Hmm..., I get it, but Im not gonna lie it's pretty confusing given that in other places // works as a substitute for /. Maybe it should be mentioned in the documentation?

Hmm..., I get it, but Im not gonna lie it's pretty confusing given
that in other places // works as a substitute for /. Maybe it
should be mentioned in the documentation?

In Linux, the system resolves "//" as just "/". In other POSIX systems, such as Cygwin or MSYS2 (running in Windows), "//" is a UNC path of the form "//server/share/filepath". I would expect resolve() to handle this. For example:

Linux:

    >>> p = pathlib.Path('//tmp')
    >>> p
    PosixPath('//tmp')
    >>> p.resolve()
    PosixPath('/tmp')

However, resolve() is broken for a UNC path in 3.9 under MSYS2:

    >>> p = pathlib.Path('//localhost/C$/temp')
    >>> p.exists()
    True
    >>> p.resolve()
    PosixPath('/localhost/C$/temp')
    >>> p.resolve().exists()
    False

realpath() is also broken for this case in 3.9 under MSYS2:

    >>> os.path.realpath(p)
    '/localhost/C$/temp'

gh-91317: Document that Path does not collapse initial `//` (GH-32193)

pythongh-91317: Document that Path does not collapse initial `//` (py…

gh-91317: Document that Path does not collapse initial `//` (GH-32193)

Revert 30935 defer bpo45162 to 312 (#94285)

Navigation Menu

pathlib method relative_to doesnt work with // in paths #91317

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

pathlib method relative_to doesnt work with // in paths #91317

Description

Activity

John15321 commented on Mar 30, 2022

arhadthedev commented on Mar 30, 2022

arhadthedev commented on Mar 30, 2022

arhadthedev commented on Mar 30, 2022

John15321 commented on Mar 30, 2022

arhadthedev commented on Mar 30, 2022

John15321 commented on Mar 30, 2022

eryksun commented on Apr 1, 2022

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions