Accepting a host component, other than localhost, raises a question about validity of the used host name. For example, browsers seem to totally ignore the host component and accept paths like file://whatever/home/peke/test in my case. I believe Python should be more strict, though, and raise a ValueError is the host component doesn't match the system where the code is run. Although the RFC mandates the host component to be fully qualified, I believe accepting only the host name should be fine too. If someone wants to parse file URIs with different host names, they can use urilib.parse.urlparse instead.

It might be that UNC Windows file paths even further. I tested this on Windows and there this usage makes sense:

>>> p = Path(r'\\host\path')
>>> print(p.as_uri())
file://host/path/
>>> p == Path.from_uri(p.as_uri())
True

Perhaps from_uri behavior should depend on the operating system.

All URIs with non-empty, non-localhost authorities parse as Path objects that start with a double slash, so it should be straightforward to reject these paths:

path = Path.from_uri('file://server/share/foo.txt')
if path.as_posix().startswith('//'):
    raise ValueError('Non-local file URI')

We could add a local_authorities argument so that users can override the ['', 'localhost'] defaults

Explicitly rejecting paths would certainly be better than returning invalid paths. Including socket.getfqdn() and possibly also socket.gethostname() in the list of local authorities could be more convenient than requiring users to pass them explicitly, though. If the list is made configurable, it probably should contain localhost and the empty string by default.

This probably would anyway require special handling on Windows. On POSIX something like Path.from_uri('file://host/path') should yield Path('/path'), assuming that host is detected to be a local authority, but on Windows throwing the host part away would break UNC paths.

We should try to be consistent across OSs unless we really must diverge IMO.

Explicitly rejecting paths would certainly be better than returning invalid paths.

Paths starting with two slashes are valid on both Windows and POSIX. On Windows they're UNC paths, whereas on POSIX they're implementation-defined (ref).

It can be hard to be totally consistent across OSes. On Windows Path(r'\\host\path').as_uri() yields file://host/path/, and it makes sense that round-trip works and Path.from_uri('file://host/path/') yields Path(r'\\host\path'). In other words, the host component is preserved on Windows. On the other hand, when Path.from_uri('file://host/path/') is used on POSIX, the host component can be validated but there's, AFAIK, no way to preserve it and the return value can only be Path('/path').

There's already other functionality in pathlib that's operating system dependent and I don't see why from_uri couldn't be as well. Someone needing, for example, Windows semantics on POSIX could then explicitly use PureWindowsPath.

I should have used "incorrect" instead of "invalid" in my earlier comment. Although Path('//hello/world') is valid, it certainly isn't the correct return value Path.from_uri('file://hello/world') on POSIX.

Upon further consideration, I've adjusted my PR so that:

• If the authority is empty or 'localhost', we suppress it.
• Otherwise, if we're on Windows, we return a UNC path
• Otherwise, if the authority resolves to a loopback address, we suppress it.
• Otherwise we raise ValueError

This is basically the same logic as urllib.request.FileHandler.file_open(), and so in a future patch I'm planning to slim down the urllib code.

Fixed in 3.14

A new test added in #126844 fails on FreeBSD:

https://buildbot.python.org/#/builders/1255/builds/457/steps/6/logs/stdio

======================================================================
ERROR: test_url2pathname_posix (test.test_urllib.Pathname_Tests.test_url2pathname_posix)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/pull_request.opsec-fbsd14/build/Lib/test/test_urllib.py", line 1562, in test_url2pathname_posix
    self.assertEqual(fn(f'//{socket.gethostname()}/foo/bar'), '/foo/bar')
                     ~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/buildbot/buildarea/pull_request.opsec-fbsd14/build/Lib/urllib/request.py", line 1658, in url2pathname
    raise URLError("file:// scheme is supported only on localhost")
urllib.error.URLError: <urlopen error file:// scheme is supported only on localhost>
----------------------------------------------------------------------

Can reproduce locally in a VM.

socket.gethostbyname(socket.gethostname()) raises gaierror(8, 'Name does not resolve').

>>> socket.gethostbyname(socket.gethostname())
Traceback (most recent call last):
  File "<python-input-1>", line 1, in <module>
    socket.gethostbyname(socket.gethostname())
    ~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^
socket.gaierror: [Errno 8] Name does not resolve

The above test failure was fixed in #132523

Re-opening to discuss this point from Serhiy on #126844:

url2pathname() now performs network requests (and hang for a time).

Having given it more thought, I reckon we should call gethostbyname() only when a new resolve_netloc keyword-only argument is set to true (default false). Existing users of this function probably don't expect it to perform network access, and it could have larger consequences in environments where DNS resolution is borked.

Thoughts / 👍 / 👎?

You just read my mind. I was thinking about suggesting adding a keyword argument for resolving hostname, but then I thought that url2pathname() may be not much used in third-party code, it may be not worth a hassle.

But adding an option is safer. In future we can even change its default value, but the users will be able to request the old behavior.

Also FYI, I'm seeing idna encoding errors on one of my private test machines from the address = socket.gethostbyname(authority) line. I'm not entirely sure what path is being passed in to cause it, but I suspect we ought to swallow UnicodeEncodeError in _is_local_authority anyway?