If params=... is passed then replace any existing query parameters, rather than merge them.

[tomchristie]

Prompted by #2712 (comment).

Currently when the URL contains existing query parameters and the params=... argument is passed, we merge the sets of query parameters...

>>> httpx.Request('GET', 'http://example.com?a=1', params={'b': '2'})
<Request('GET', 'http://example.com?a=1&b=2')>

This seems a bit counter-intuitive to me - I'd probably(?) expect them to be replaced, rather than merged.

Is it worth us changing this behaviour?

Implemented here...

httpx/httpx/_models.py

Line 330 in a682f6f

self.url = self.url.copy_merge_params(params=params)

[Tunglies]

How about giving a keyword and decide replace or merge, likes httpx.Request('GET', 'http://example.com?a=1', params={'b': '2'}, replace=True)

[tomchristie]

Hrrmmm...

We can do this being explicit:

url = httpx.URL('http://example.com?a=1').copy_with(params=...)  # Replaces params
url = httpx.URL('http://example.com?a=1').copy_merge_params(...)  # Merges params
r = httx.Request('GET', url)

[michaeloliverx]

would this include replacing query params that were passed in the Client(params={}) instantiation?

[zanieb]

Hm, I think I'd expect merge with the ability to "remove" parameters with {'key': None} but I'm not sure what use-cases there are for providing a URL with existing parameters. It seems like why you would end up in this situation is important for determining the expected behavior.

[tomchristie]

@tomchristie - I'm nudging this issue into a discussion. If we reach a design consensus then we can escalate it into an issue.

[rafalkrupinski]

This seems a bit counter-intuitive

They have now very clear semantics, same as cookies (more or less) and headers: they're common values, used by all requests.
If it's not common, don't put it there :)

Would having a sub-clients that share the connection pool be a solution? Something kinda like URL.copy_with().

Hm, I think I'd expect merge with the ability to "remove" parameters with {'key': None}

Slippery road of having separate semantics for None and key not present ;)
But yeah, why not.