Issue 23416: Make urllib.parse.SplitResult etc arguments optional (original) (raw)

This would be a simple API enhancement and would allow easier building of URLs, like

SplitResult("rtp", address, query=urlencode(query)).geturl() "rtp://localhost:5004?rtcpport=5005"

It seems the best way to do this at the moment is annoyingly verbose:

SplitResult("rtp", address, path="", query=urlencode(query), fragment="").geturl()

The way hinted by the documentation can leave an ugly empty query string:

query = () "rtp://%s?%s" % (address, urlencode(query)) "rtp://localhost:5004?"

This enhancement would also allow easy parsing of usernames, ports, etc:

SplitResult(netloc="[::1]:0").hostname "::1" SplitResult(netloc="[::1]:0").port 0

Looking at the code, I think this could be implemented by adding an explicit constructor to each of the concrete classes, with arguments defaulting to "" or b"" as appropriate.

I agree that it would be nice to have. But this feature has a cost.

$ ./python -m timeit -s 'from urllib.parse import ParseResult' -- "ParseResult('http', 'User@example.com:Pass@www.python.org:080', '/doc/', '', 'query=yes', 'frag')" Unpatched: 1.61 usec per loop Patched: 2.1 usec per loop

$ ./python -m timeit -s 'from urllib.parse import urlparse' -- 'urlparse("http://User@example.com:Pass@www.python.org:080/doc/?query=yes#frag")'

Unpatched: 8.87 usec per loop Patched: 9.22 usec per loop

Is this cost significant?

The cost can be decreased by using global _tuple_new = tuple.new. But this couples the code too tight to implementation details of namedtuple.