The presence of "During handling of the above exception, another exception occurred:" is part of an intentional change between 2.x and 3.x. Exception handling has been tweaked a bit more in the past year. 3.2.3 only gives the second half of the traceback, which I suppose is worse.

In 3.3.0, the exception raising an exception behavior is fixed for this particular input on my Win 7 system.

>>> import urllib.request
>>> urllib.request.urlretrieve('missing')
Traceback (most recent call last):
  File "<pyshell#1>", line 1, in <module>
    urllib.request.urlretrieve('missing')
  File "C:\Programs\Python33\lib\urllib\request.py", line 185, in urlretrieve
    with contextlib.closing(urlopen(url, data)) as fp:
  File "C:\Programs\Python33\lib\urllib\request.py", line 160, in urlopen
    return opener.open(url, data, timeout)
  File "C:\Programs\Python33\lib\urllib\request.py", line 458, in open
    req = Request(fullurl, data)
  File "C:\Programs\Python33\lib\urllib\request.py", line 279, in __init__
    self._parse()
  File "C:\Programs\Python33\lib\urllib\request.py", line 284, in _parse
    raise ValueError("unknown url type: %s" % self.full_url)
ValueError: unknown url type: missing

urlretrieve no longer assumes the file: scheme. (It was never documented to do so, and there is no good reason to do so.) If given explicitly with an invalid name, it gives the current equivalent of the 2.x error and message.

>>> urllib.request.urlretrieve('file:missing')
...
urllib.error.URLError: <urlopen error [WinError 2] The system cannot find the file specified: 'missing'>

Nonetheless, this 3 arg call should be fixed
1887 except OSError as e:
1888   raise URLError(e.errno, e.strerror, e.filename)