Is there a reason for this raising, catching and reraising the exception here:

https://github.com/python/cpython/blob/main/Lib/urllib/parse.py#L934


rather than just:

if len(query) and not isinstance(query[0], tuple):
    raise TypeError("not a valid non-string sequence "
                    "or mapping object")

?

In urllib.request, there are in a few places things like:

  except OSError as msg:
     raise OSError('socket error', msg).with_traceback(sys.exc_info()[2])


I imagine this predates chaining - is there a reason not to raise..from here instead of wrapping the "msg" exception (I'm guessing from the name that this used to be a string, but now it's actually an exception).

Note that test.support has special handling for urllib's nested exception structure:

https://github.com/python/cpython/blob/3.10/Lib/test/support/socket_helper.py#L250

The linked code is for urllib.parse.urlencode, looking something like

try:
    if len(query) and not isinstance(query[0], tuple):
        raise TypeError
except TypeError:
    ty, va, tb = sys.exc_info()
    raise TypeError("not a valid non-string sequence "
                    "or mapping object").with_traceback(tb)

I guess it raises twice so that the error message is not duplicated in the code. The author probably also wants the TypeError initially raised from the "len(query)" and "query[0]" operations to get the same "not a valid . . ." message.

Regarding the OSError, originally it was catching socket.error and raising IOError. I guess someone only wanted the caller to have catch IOError and not need to import the socket module. Later these exception types became aliases of each other.

Anyway, the URLopener class is documented as deprecated, so is it really worth changing anything in that?

> The author probably also wants the TypeError initially raised from the "len(query)" and "query[0]" operations to get the same "not a valid . . ." message.

I see.


I didn’t realise it’s deprecated, I guess we’ll leave it alone then. Thanks.