While fixing this issue is easy, there is a wider problem with the use of URLError.
The constructor accepts two args, reason and filename. About half of the errors in Lib/urllib/request.py use only one argument, and in the other half not a single one uses the second arg for the filename:

raise URLError('file error', 'proxy support for file protocol currently not implemented')
raise URLError('local file error', 'not on local host')
raise URLError('ftp error', 'proxy support for ftp protocol currently not implemented')
if not host: raise URLError('ftp error', 'no host given')
raise URLError('ftp error', msg).with_traceback(sys.exc_info()[2])
raise URLError('data error', 'proxy support for data protocol currently not implemented')
raise URLError('ftp error', reason).with_traceback(
raise URLError('ftp error', reason) from reason

Note that the only the first arg ends up in the error message.

This should be reported in another issue though.


In the attached patch I passed only the first argoment and did

-            raise URLError(e.errno, e.strerror, e.filename)
+            raise URLError('local file error')

The result is

Traceback (most recent call last):
  File "/home/wolf/dev/py/3.2/Lib/urllib/request.py", line 1769, in open_local_file
    stats = os.stat(localname)
OSError: [Errno 2] No such file or directory: 'foo'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/wolf/dev/py/3.2/Lib/urllib/request.py", line 1771, in open_local_file
    raise URLError('local file error')
urllib.error.URLError: <urlopen error local file error>

If that's OK I'll add a couple of tests and commit.