Replies: 1 comment 2 replies
-
I'm not 100% against differentiating between The alternate approach is to include query params directly on the URL string, eg... r = httpx.get('https://httpbin.org/get?key2') On the basis of emoji responses to this comment... psf/requests#2651 (comment) ...it seems like there's a decent bit of support for this. The details are likely to be far more fiddly that you might suspect at first. For example, the type signatures of various methods on Line 484 in eb7433b ...would become... def get_list(self, key: typing.Any) -> typing.List[Typing.Optional[str]] Also implementation-wise it looks like it could well be unexpectedly gnarly. We lean on https://github.com/encode/httpx/blob/eb7433bf8edc90f064adcaedfd4897f9c059d8d7/httpx/_models.py#L445 I don't think that has any way of differentiating between the |
Beta Was this translation helpful? Give feedback.
-
I guess this is a followup to #1261. Please reconsider this:
https://www.python-httpx.org/compatibility/
IMO it would be good and fine to break
requests
compatibility here.I doubt many put a no-op
"foo":None
entry intoparams
when using requests and it's likely nobody has onhttpx 0.x
.Query args without an equal sign are in wide usage. E.g. elasticsearch's apis with
?pretty
to format the json response or AWS' apis:https://docs.aws.amazon.com/AmazonS3/latest/userguide/RESTAuthentication.html#ConstructingTheCanonicalizedResourceElement
It's true most apis treat
?foo
like?foo=
or?foo=true
but there are apis that treat?foo=
like?foo=false
.Yes clients probably should give query args explicit values but sometimes you want to use or test an api with a specific url, and httpx should let you construct any legal url.
This is the current requests-compatible but imo undesirable behavior:
Desired behavior:
Beta Was this translation helpful? Give feedback.
All reactions