I’m confused what the intention of this bug is. The normal urllib.request.urlopen() function (or equivalent) still allows file URLs with relative paths, in various Python versions I tried, ranging from 2.6 to 3.5:

>>> import urllib.request
>>> urllib.request.urlopen("file:README")
<addinfourl at 140061019639088 whose fp = <_io.BufferedReader name='README'>>

Passing a relative URL without a scheme seems to have never been supported, for a different reason:

>>> urllib.request.urlopen("README")
Traceback (most recent call last):
[. . .]
  File "/home/proj/python/cpython/Lib/urllib/request.py", line 321, in _parse
    raise ValueError("unknown url type: %r" % self.full_url)
ValueError: unknown url type: 'README'

Looking closer at the changes made here, they only seem to affect the urllib.request.URLopener class, which is listed as deprecated in 3.3 and never used by urlopen() as far as I know.

Personally, I would prefer to keep allowing relative paths in “file:” scheme URLs in urlopen(). This is useful e.g. if you don’t want to put the full working directory in a URL on the command line or whatever.

It is inconsistent that urljoin(), urlunsplit(), etc don’t support relative paths, but I would actually prefer that such support be added. (I think my patch for Issue 22852 would probably do the trick.) Currently, urljoin() reinterprets the path as absolute:

>>> urljoin("file:subdir/index.html", "link.html")
'file:///subdir/link.html'