nturl2path.pathname2url() doesn't handle forward slashes

Bug report

Bug description:

Paths with forward slashes aren't handled the same as paths with backslashes:

>>> from nturl2path import pathname2url
>>> pathname2url('//?/unc/server/share/dir')
'//%3F/unc/server/share/dir' # NOK
>>> pathname2url(r'\\?\unc\server\share\dir')
'//server/share/dir' # OK

CPython versions tested on:

3.13

Operating systems tested on:

Windows

Linked PRs

GH-120423: pathname2url(): handle forward slashes in Windows paths #126593
[3.12] GH-120423: pathname2url(): handle forward slashes in Windows paths (GH-126593) #126763
[3.13] GH-120423: pathname2url(): handle forward slashes in Windows paths (GH-126593) #126764

Quoting @eryksun:

The standard library doesn't use urllib.request.pathname2url(), so it isn't currently an internal issue. However, the documentation claims to support "the local syntax for a path", which would include using forward slash as the path separator. The Windows implementation of pathname2url() is tested in "Lib/test/test_urllib.py", but AFAICT only with backslash as the path separator. I think the input path should be normalized via normpath() and then split via splitroot() to process it sanely.

Also, currently nothing else in the standard library uses the nturl2path module, and its existence isn't documented. The two functions could be defined directly in urllib.request. The way some of the tests are implemented would have to be updated as well.

While using an empty authority (i.e. hostname or namespace) for a UNC path is valid according to RFC8089 (e.g. "file:////spam/eggs/foo"), the two-slash form with an authority is preferred on Windows (e.g. "file://spam/eggs/foo"). For DOS drive paths, the form with an empty authority is preferred (e.g. "file:///C:/eggs/foo"). But using an explicit authority is also supported (e.g. "file://localhost/C:/eggs/foo", or sometimes "file://./C:/eggs/foo").

On POSIX, urllib.request.pathname2url() simply calls quote(), so you might expect to use it like this:

>>> 'file://' + urllib.request.pathname2url('/etc/hosts')
'file:///etc/hosts'

But if we try the same thing using the Windows version we get unusual results:

>>> 'file://' + nturl2path.pathname2url(r'c:\foo')
'file://///C:/foo'
>>> 'file://' + nturl2path.pathname2url('c:/foo')
'file://///C://foo'
>>> 'file://' + nturl2path.pathname2url(r'\\server\share\file')
'file://////server/share/file'
>>> 'file://' + nturl2path.pathname2url('//server/share/file')
'file:////server/share/file'

I don't think there's a way to use it correctly. IMHO we should deprecate + remove it.

We can recommend Path.as_uri() to users as a replacement. It's been available since pathlib was added to the standard library.

It's tempting to also deprecate and remove url2pathname(), but:

It's used a couple of times internally (unlike pathname2url()), and
The potential replacement (Path.from_uri() was only added in 3.13, and if we want to be kind to package maintainers, I think we ought to wait until 3.12 drops out of support.

We can recommend Path.as_uri() to users as a replacement. It's been available since pathlib was added to the standard library.

It's tempting to also deprecate and remove url2pathname(), but:

It's used a couple of times internally (unlike pathname2url()), and

The potential replacement (Path.from_uri() was only added in 3.13, and if we want to be kind to package maintainers, I think we ought to wait until 3.12 drops out of support.

If we want to encourage usage of Path.from_uri over url2pathname wouldn't that justify a depreciation notice, at least a recommendation in the docs?

#126148 will fix this

Thanks, I was already wondering if that was the case.

pythonGH-120423: `pathname2url()`: handle forward slashes in Windows …

I decided to solve URL parsing/generation problems piecemeal rather than doing everything in #126148

Specific PR available: #126593

GH-120423: `pathname2url()`: handle forward slashes in Windows paths (#…

pythonGH-120423: `pathname2url()`: handle forward slashes in Windows …

[3.12] GH-120423: `pathname2url()`: handle forward slashes in Windows…

[3.13] GH-120423: `pathname2url()`: handle forward slashes in Windows…

Fixed! Thanks for your input, all.

pythonGH-120423: `pathname2url()`: handle forward slashes in Windows …

Navigation Menu

`nturl2path.pathname2url()` doesn't handle forward slashes #120423

Bug report

Bug description:

CPython versions tested on:

Operating systems tested on:

Linked PRs

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

nturl2path.pathname2url() doesn't handle forward slashes #120423

Description

Bug report

Bug description:

CPython versions tested on:

Operating systems tested on:

Linked PRs

Activity

nineteendo commented on Jun 12, 2024

eryksun commented on Jun 12, 2024

barneygale commented on Jun 12, 2024

barneygale commented on Jun 12, 2024

pygeek commented on Jun 13, 2024

barneygale commented on Oct 30, 2024

nineteendo commented on Oct 30, 2024

barneygale commented on Nov 8, 2024

barneygale commented on Nov 12, 2024

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions

`nturl2path.pathname2url()` doesn't handle forward slashes #120423