The case for immutable QueryParams
#1599
Unanswered
tomchristie
asked this question in
Ideas
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I'd like to propose a change to our
QueryParams
interface, starting with 0.18.Our
URL
model is immutable, which is a very nice sensible property for it to have. Similarly, the hyperlink package has the same design constraint there.Changing a URL always creates a new instance, eg.
url = url.copy_with(scheme="https")
However, our
QueryParams
model is currently mutable. So eg.q["a"] = "123"
orq.update({"a": "123"})
both change the existing instance, rather than returning a new one. That's actually a bit of a grungy design difference vs. our URL model.It also has an awkward impact. I'd like us to be able to add a
url.params
property, since it makes sense in terms of consistency of our API. But it wouldn't currently work in a neat way, because eg... it'd allow for weird usages likeurl.params["a"] = "123"
which looks like it'd mutate the URL, but actually wouldn't have any effect. It would mutate a QueryParams instance that's returned by theurl.params
property, and then discard it.An immutable
QueyParams
model would just be plain nicer all round.I'd suggest we drop
__setitem__
andupdate()
and instead have an API of methods that each return new instances.Following
hyperlink
, we'd likely wantset()
,add()
, andremove()
:Really we also want an equivalent of
.update(other)
, although I think it's better not to name itupdate
since that more easily lead to unexpected coding errors, given expectations thatdict.update
is a mutating method, so I'd suggest.merge(other)
:We could either do this with a deprecation period for
__setitem__
andupdate
, or else issue it as an outright change.Our exposure here is pretty low - we don't actually document any of the QueryParam mutating methods anywhere in the docs, and are only exposing them for nice API consistency. The only place we use them internally is a single case in the client where we merge the client params with any per-request params.
It'll also let us extend out the
URL
model in a neat way, so that...A further neat extension to really round out our URL manipulation would then be to add the following...
To support usages such as...
Beta Was this translation helpful? Give feedback.
All reactions