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

[nineteendo]

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

[nineteendo]

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.

[eryksun]

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").

[barneygale]

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.

[barneygale]

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:

1. It's used a couple of times internally (unlike pathname2url()), and
2. 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.

[pygeek]

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:

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

2. 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?

[barneygale]

#126148 will fix this

[nineteendo]

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

[barneygale]

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

Specific PR available: #126593